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ABSTRACT 


AMBIT/G  is  an  experimental  language  for  software  programming .  It  is 
oriented  toward  the  manipulation  of  complicated  data  structures.  Two- 
dimensional  directed-graph  diagrams  are  used  to  represent  the  data,  and 
similar  diagrams  are  used  throughout  the  program  as  the  "patterns"  of 
rules  to  modify  the  data.  An  AMBIT/G  system  has  been  implemented  on 
the  Multics  System  at  M.I.T.  The  implementation  is  ostensive  and  is 
intended  for  experiments  in  the  use  of  AMBIT/G.  It  is  written  partly  in 
AMBIT/G  and  partly  in  PL/I.  This  report  begins  with  fundamental  concepts 
and  then  proceeds  to  describe  the  implementation  in  great  detail.  The 
AMBIT/G  programs  for  the  AMBIT/  G  interpreter  and  the  AMBIT/G  loader 
arc  described  and  then  displayed  in  full.  Instructions  for  the  input, 
execution,  and  debugging  of  a  user  program  are  given.  Many  examples 
are  included,  carefully  chosen  to  illustrate  and  teach  important  features 
of  AMBIT/G. 
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CHAPTER  1 


SUMMARY 

This  report  is  large.  However,  the  casual  reader  can  obtain  a  useful 
introduction  to  AMBIT/G  by  reading  a  few  pages  of  the  first  two  volumes. 
Specifically,  we  suggest  that  he  begin  with  the  next  chapter  of  this  volume, 
on  fundamentals,  and  then  read  the  first  three  sections  of  the  second  volume, 
concluding  with  the  introductory  examples,  three  programs  for  reversing  the 
order  of  a  list. 

The  report  is  large  because  it  contains  many  complete  AMBIT/G  pro¬ 
grams  and  because  these  programs  require  diagrams  rather  than  text  for  their 
representation.  The  general  trend  of  the  report  is  from  general  and  philosoph¬ 
ical  discussion  to  detailed  and  practical  specifications.  At  the  beginning 
we  do  not  assume  a  prior  knowledge  of  AMBIT/G,  and  at  the  end  we  give 
listings  of  large  and  complicated  AMBIT/G  programs.  Much  of  this  information 
is  the  unrefined  output  of  our  current  research  on  AMBIT/G  and  therefore  is 
not  presented  in  a  tutorial  way. 

After  the  chapter  on  fundamentals,  the  report  proceeds  to  its  main 
business,  which  is  the  definition  and  implementation  of  the  AMBIT/G  system. 

The  definition  and  implementation  are,  in  fact,  partly  Identical  since  some  of 
the  implementation  is  written  in  AMBIT/G.  Chapter  3  gives  the  representation 
of  AMBIT/G  programs  in  the  form  of  AMBIT/G  data  and  provides  the  basis  for 
accepting  a  program  as  a  data  structure  on  which  an  interpreter  program  can 
operate.  The  chapter  makes  use  of  an  interesting  formalism  for  the  specification 
of  "grammars"  for  AMBIT/G  data. 

Once  we  have  a  way  of  thinking  of  a  program  as  data,  we  can  discuss 
an  interpreter.  Chapter  4  describes  the  AMBIT/G  program  (given  in  Volume  III) 
which  is  our  interpreter.  An  especially  Important  part  of  this  chapter  is  a 
discussion  of  the  definition  and  use  of  functions  in  AMBIT/G. 

Our  implementation  of  AMBIT/G  requires  that  both  data  and  programs 
are  presented  to  the  system  in  an  abstract  input  language  (as  textual  descrip¬ 
tions  of  diagrams).  Chapter  5  describes  an  AMBIT/G  program  (given  in  Volume 
IV)  which  "loads"  pages  of  this  input  to  produce  an  internal  data  graph.  Tho 
chapter  gives  a  formal  syntax  for  the  input  language  and  Includes  an  example 
of  the  use  of  the  loader. 
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The  AMBIT/G  System  is  not  empty  when  a  user  program  arrives  for 
interpretation.  Certain  information  on  the  requirements  of  the  program  must 
be  submitted  in  advance.  More  important,  a  variety  of  nodes,  links, 
functions,  rules,  and  pre-set  data  is  built  into  the  system  in  order  to  give 
the  user  a  practical  point  of  departure  for  programming.  These  facilities 
are  described  in  Chapter  6. 

A  special  subsystem  for  symbolic  debugging  is  included  in  the 
AMBIT/G  System,  so  that  the  user  may  inspect  the  data  in  a  natural  and 
interactive  way.  Chapter  7  describes  the  use  of  this  subsystem  in  detail. 

Although  the  interpreter  and  loader  are  both  written  in  AMBIT/G, 
there  is  necessarily  an  underlying  foundation  for  our  Multics  implemen¬ 
tation.  This  foundation  is  composed  of  PL/I  routines  and  is  described  in 
great  detail  in  Chapter  8. 

Chapter  9  contains  some  suggestions  for  further  work  on  the  imple¬ 
mentation.  The  first  volume  concludes  with  an  annotated  bibliography  of 
the  papers  and  programs  which  have  been  produced  by  the  project  or  are 
related  to  the  project. 

The  second  volume  consists  entirely  of  example  programs.  It  is 
these  examples  which  best  display  the  concepts  of  AMBIT/G.  In  fact, 
nearly  every  example  was  chosen  to  illustrate  a  particular  aspect  of  the 
AMBIT/G  System. 

We  have  already  noted  that  the  last  two  volumes  are  the  complete 
program  listings  for  the  interpreter  and  the  loader.  These  listings  are 
included  in  the  report  for  three  reasons:  The  programs  contribute  to  the 
formal  definition  of  AMBIT/G,  they  form  the  basis  for  the  implementation, 
and  they  are  large-scale  examples  of  AMBIT/G  programming. 

The  scope  of  this  report  is  limited  to  the  definition  and  implementation 
of  AMBIT/G  and  does  not  include  other  work  done  as  part  of  the  project.  The 
interested  reader  is  directed  especially  to  our  work  on  character  recognition 
(Ledeen  and  Wolfberg) ,  formal  definition  of  BASEL  (Jorrand  and  Hammer) , 
description  of  simple  AMBIT/G  (Henderson) ,  constraints  (Third  Semi-Annual 
Report),  and  the  design  of  AMBIT/L  (Christensen). 


2 


CHAPTER  2 


FUNDAMENTALS 


The  project  "Research  In  Machine-Independent  Software  Programming" 
is  devoted  to  the  capture  and  analysis  of  the  techniques  of  software 
construction.  By  tradition  and  necessity,  these  techniques  have  been 
expressed  fully  only  in  machine-language  programs;  and  in  that  form  they 
are  as  obscure  and  exotic  in  our  times  as  the  operations  of  arithmetic  were 
in  the  European  Middle  Ages .  We  seek  a  significant  remedy  to  this 
situation  by  breaking  away  from  current  programming  languages  and 
following  a  fundamentally  new  approach  to  software  programming.  The 
practical  results  of  this  speculative  venture  are  incorporated  in  an 
experimental  programming  system  called  AMBIT/G. 

The  AMBIT/G  programming  system  is,  first  of  all,  a  high  level 
system  for  the  construction  of  software.  The  term  "high  level"  is 
often  applied  to  a  programming  language  to  indicate  the  use  of  some 
combination  of  English  and  mathematical  notation.  We  intend  a  more 
general  use  of  the  term.  In  our  broader  sense,  a  successful  high  level 
system  provides  a  complete  framework  of  concepts  and  techniques  for 
programming  in  addition  to  a  language;  that  is,  it  channels  and  supports 
the  thoughts  of  the  programmer  as  well  as  his  utterances. 

Our  work  on  AMBIT/G  has  a  simple  underlying  assumption.  We 
believe  that  the  characteristic  activity  of  software  construction  is  the  design 
and  use  of  complicated  data  structures,  such  as  stacks,  queues,  rings, 
lists,  and  special  tables.  Indeed,  the  most  important  "construction"  activity 
seems  to  be  the  structuring  of  data  rather  than  programs.  Accordingly, 
AMBIT/G  is  data-oriented  to  an  unprecedented  extent.  At  the  beginning  of 
a  new  programming  task,  the  AMBIT/G  user  establishes  a  formal  and 
"machinable"  statement  of  the  representation  and  properties  of  his  data.  Only 
when  his  data  design  is  complete  does  he  begin  programming. 
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English  And  algebra,  as  used  In  COBOL,  FORTRAN,  and  PL/I. 
for  example ,  arc  an  effective  combination  for  commercial  and  scientific 
programming.  However,  those  textual,  essentially  linear  notations  are  not 
a  natural  medium  for  the  description  of  structure  In  general  or  software 
data  structures  in  particular.  AMBIT/G  rejects  these  notations  In  favor 
of  another  high  level  medium,  the  diagram. 

The  expository  value  of  a  diagram  Is  well  known.  Flow  charts 
of  programs  are  very  familiar  and  (more  relevant  to  the  present  discourse) 
Informal  diagrams  of  data  have  been  used  for  years  to  supplement  program 
documentation.  On  the  other  hand,  the  formal  adoption  of  a  diagram  as 
the  "actual"  data  is  quite  unique  to  AMBIT/G  and  has  a  powerful  effect; 
the  diagram  becomes  an  almost  machine-like  object,  changing  frequently 
in  certain  places  and  relatively  fixed  In  others,  a  passive  machine 
operated  by  a  program  but  subject  to  Its  own  built-in  constraints. 

THE  DATA  GRAPH 

An  early  use  of  informal  data  diagrams  was  in  the  representation 
of  LISP  lists,  and  many  variations  have  since  been  used  in  papers  on 
software .  We  obtained  a  formal  model  for  data  by  restricting  and  simpli¬ 
fying  the  notation  rather  than  elaborating  It.  The  final  result  is  a  precisely 
defined  form  of  diagram  called  a  data  graph.  The  following  diagram  is  an 
example  of  a  (small)  data  graph. 
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The  diagram  Is  composed  of  nodes  and  links.  A  node  Is  a  rectangle  with 
a  node  name  written  Inside;  this  node  name  Is  a  type  written  above  a 
subname .  There  may  be  many  nodes  of  a  given  type,  and  these  are 
distinguished  from  one  another  by  their  subnames.  In  the  diagram  above, 
for  example,  there  are  eight  nodes  of  type  'CELL';  their  subnames  are  the 
integers  from  '20'  through  '27'.  A  link  is  a  line  which  begins  at  an  origin 
node,  passes  close  to  its  link  name,  and  ends  (with  an  arrowhead)  at  a 
destination  node.  Every  node  of  a  given  type  has  a  similar  set  of  links. 

For  example,  every  'CELL*  In  the  diagram  is  the  origin  of  four  links  which 
are  named  'flag',  'r',  's',  and 'd',  and  every  'SYM'  is  the  origin  of  no  links. 
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The  types,  subnames.  And  link  names  uitd  In  the  data  graph 
art*  sel«*<  led  fey  th«* -crooffliBiwr  for  t>ach  particular  program.  It  It  tha 
facility  for  feyiUiDS  special  data  itructurtt.  not  tha  structural  them- 
#*  Ives.  which  i»  built  into  the  AMBIT /C  system. 

t  vry  i.i  tn  graph  must  be  functional,  that  Is.  a  given  node 
(is  origin  of  a  link)  and  a  given  identifier  (as  link  name)  must  specify 
no  more  than  one  node  (as  destination  of  the  link).  This  allows 
the  u  .ambiguous  specification  of  a  'walk'  along  the  Unkt  of  a  diagram 
by  giving  a  starting  node  name  and  a  sequence  of  link  names.  Purpose¬ 
ful  link  walking  is  an  important  activity  of  software  programs. 

The  data  graph  must  also  be  permanent:  that  is.  nodes  and  links 
cannot  be  created  or  destroyed  during  program  execution.  In  fact,  the 
only  permitted  operation  is  the  'swinging'  of  a  link  so  that  Its  pointed 
end  moves  from  one  node  to  another.  This  restriction  redacts  tha  fact 
that  machines  (including  memory  hardware)  tend  to  be  permanent. 

Once  the  fundamental  data  representation  has  been  established, 
certain  superficial  but  useful  'abbreviations'  are  Introduced.  For 
example,  the  type  is  dropped  from  within  a  node  boundary  and  is  Indi¬ 
cated  by  giving  the  node  boundary  itself  e  distinctive  shape.  Or  link 
names  are  dropped  by  establishing  for  each  different  link  a  characteristic 
point  of  origin  on  the  node  boundary.  Such  convenience  notations  make  the 
diagram  much  more  readable. 

We  do  not  intend  that  the  programmer  write  out  a  large  data  graph; 
an  architect  does  not  draw  every  brick  and  nail  of  his  building.  However, 
the  postulated  existence  of  the  data  graph  provides  a  reliable  basis  for  the 
programmer's  thinking.  It  is  the  basis  for  the  design  of  constraints  on 
data  and  the  writing  of  proorams. 
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CONSTRAINTS 


If  a  data  graph  has  £  nodes,  then  each  link  In  the  data  graph 
has  £  states,  one  for  each  possible  destination.  Further,  if  the  data 
graph  has  a  total  of  k  links,  then  the  entire  data  graph  has  n  different 
states . 


The  programmer  uses  formal  statements  called  constraints  to 
stipulate  that  certain  states  of  the  data  graph  can  never  occur  during 
the  execution  of  his  program.  A  constraint  may  fix  a  given  link  to  a 
single  destination  for  all  time;  or  it  may  restrict  the  link  to  destinations 
of  a  specified  type;  or  it  may  establish  a  more  general  and  dynamic 
dependency  of  the  link  on  other  links.  When  a  program  is  being  debugged, 
the  program  interpreter  (a  human  reader  or  computer  executor)  can  check 
for  operations  on  the  data  which  are  inconsistent  with  the  constraints 
and  report  these  to  the  programmer. 

Ultimately  the  data  graph  must  be  encoded  in  bits  and  stored  in 
some  computer  memory.  The  amount  of  computer  memory  required  will  be 
a  function  of  the  number  of  states  available  to  the  data  graph;  therefore, 
constraint  of  the  data  graph  reduces  the  memory  required.  Thus  constraints 
are  useful  both  for  debugging  the  program  and  for  optimization  of  storage. 
Constraints  are  a  vital  and  growing  aspect  of  AMBIT/G. 

An  AMBIT/G  program  includes  a  collection  of  rules  connected  by 
flow  lines  as  in  a  flow  chart.  Each  rule  is  itself  a  diagram  and  uses  a 
notation  which  closely  resembles  that  of  the  data  graph.  An  example  of  a 
single  rule  is  as  follows: 
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This  rule  is  executed  when  "control"  enters  along  one  of  the  incoming 
flow  lines  at  the  left;  and  its  execution  results  in  control  exiting  to 
another  rule  along  the  success  or  fall  flow  lines  to  the  right.  The 
inside  of  the  rule  can  be  interpreted  in  three  paragraphs,  as  follows: 


First  frame  the  data  graph  as  follows:  Select  'VAR  Y' ,  follow 
the  'val'  link,  and  call  its  destination  cl.  Is  cj.  a  'CELL' 
node?  Select  cl,  follow  the  'd'  link,  and  answer:  is  its 
destination  'INT  25'?  Select  cl,  follow  the  'r'  link,  and  call  its 
destination  c2 .  Is  c2  a  'CELL'  node?  Select  c2,  follow  the 
'd'  link,  and  call  its  destination  ol.  Select  c2,  follow  the  *r* 
link,  and  call  its  destination  c3.  Is  c3  a  'CELL*  node?  (Should 
the  answer  to  a  frame  question  be  "no" ,  you  have  detected  the 
consequences  of  a  programming  error;  take  the  day  off  and  get 
undefined.) 

Next  test  the  data  graph  as  follows:  Is  o^.  an  'OP'  node?  Select 
'VAR  X',  follow  the  'val'  link,  and  answer:  is  its  destination 
c3?  (Should  the  answer  to  a  test  question  be  "no  " ,  take  the 
fall  exit  from  the  rule .) 

Finally,  (if  you  haven't  gone  away)  modify  the  data  graph  thus: 
Select  'VAR  Y'  and  set  its  'val'  link  to  point  to  c2.  Select  c3 
and  set  its  *d'  link  to  'SYM  Al'.  (No  questions  are  asked 
during  modification .  When  you  are  done ,  take  the  success  exit 
from  the  rule.) 
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The  paragraphs  just  given  imply  a  total  ordering  of  actions 
Which  we  now  revoke:  The  actions  (commands  and  questions)  within 
a  given  paragraph  can  be  interpreted  in  any  order  provided  that  each 
variable  (like  cl)  is  associated  with  a  node  in  the  data  graph  (by  a  "call" 
clause)  before  it  is  referenced  (by  a  "select"  clause). 

Every  (single-line)  link  in  any  rule  must  be  a  part  of  an 
anchored  walk.  An  anchored  walk  begins  with  a  node  whose  full  name 
(type  and  subname)  is  given  in  the  rule  and  repeatedly  "steps"  from  one 
node  in  the  rule  to  another,  each  time  following  a  link  from  origin  to  des¬ 
tination.  This  restriction  means  that  the  pattern-match  can  be  implemented 
very  efficiently;  in  fact,  none  of  the  "searching"  characteristic  of 
general  pattern-matching  is  ever  required. 

To  complete  this  discussion  of  programs,  some  remarks  on  program 
structure  (that  Is,  the  framework  In  which  rules  are  embedded)  is  necessary. 
Since  most  of  the  unusual  and  novel  concepts  of  AMBIT/G  seem  to  be 
confined  to  the  rules,  we  seriously  considered  adopting  the  program 
structure  of  some  existing  high  level  language  and  we  decided  that  ALGOL  60 
was  the  obvious  candidate.  The  use  of  an  ALGOL  60  framework  presented 
serious  problems,  however. 

The  first  problem  arose  in  finding  an  analog  to  the  ALGOL  60  function 
reference.  At  first  it  appeared  that  there  was  no  natural  place  for  functions 
in  a  pattern-mctchlng  rule.  Eventually,  however,  we  developed  the  idea 
that  the  function  reference  and  the  data  link  are  not  in  conflict  but,  rather, 
are  two  aspects  of  the  fundamental  mechanism  for  assigning  structure  to  data. 
The  function  reference  became  a  new  and  important  part  of  the  notation 
for  rules. 

Our  second  problem  arose  with  block  structure.  The  ALGOL  60 
block  structure  is  the  basis  for  automatic  storage  allocation,  and  recursive 
function  evaluation.  It  has  been  extremely  successful  and  has  become  a 
classic  component  of  high  level  languages.  However,  block  structure 
implies  hidden  mechanisms  for  storage  management  which  are  in  direct 
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conflict  with  the  objectives  of  AMBIT/G,  which  seek  to  give  the  pro¬ 
grammer  close  control  over  all  his  data.  V\fe  rejected  block  structure 
because  we  could  not  find  a  simple  and  practical  way  to  control  its 
machinery. 

Other  problems  of  a  less  fundamental  nature  arose  and  we 
were  forced,  after  all,  to  accept  a  minimal  program  structure,  far  simpler 
than  that  of  ALGOL  60,  which  involved  the  use  of  success  and  fall  flow 
lines  to  connect  rules  and  a  very  general  mechanism  for  function  definition 
and  reference. 


GENERAL  PHILOSOPHY 

The  designer  of  a  programming  language  soon  leams  that  the  goals 
he  has  set  for  himself  are  in  conflict.  A  language  should  be  powerful  yet 
easily  implemented,  rich  in  expression  yet  easily  learned,  application- 
oriented  yet  general  purpose,  concise  yet  readable,  easily  programmed  in 
yet  efficiently  compiled.  Most  existing  languages  are  readily  classified 
along  one  or  more  of  these  dimensions  and  often  are  noteworthy  because  of 
an  extreme  position  with  respect  to  one  of  them,  PL/I  is  noted  for  being 
powerful  but  difficult  to  implement;  BASIC  is  at  the  other  extreme.  ALGOL  68 
is  rich  in  expression  ;  SNOBOL  1  is  easily  learned.  SIMSCRIPT  is  application- 
oriented;  ALGOL  60  is  general  purpose.  APL  is  concise;  COBOL  attempts 
to  be  readable .  EULER  is  easily  programmed;  FORTRAN  can  be  efficiently 
compiled. 

The  motivation  in  the  design  of  AMBIT/G  was  not  simply  to  decide 
upon  a  position  with  respect  to  each  of  the  above  parameters  and  then  build 
yet  another  language,  distinguished  from  the  others  only  by  the  particular 
combination  of  choices  made.  Rather,  it  was  to  study  some  of  these  apparent 
conflicts  in  an  attempt  to  see  just  how  they  influence  language  design,  and 
based  on  the  insights  so  gained,  to  build  a  language  which  overcomes  the 
weaknesses  and  limitations  which  any  compromise,  no  matter  how  carefully 
chosen,  necessarily  imposes. 
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This  seemingly  Impossible  undertaking  has  indeed  succeeded,  at 
least  in  its  initial  stages,  and  the  particular  solutions  take  one  of  two  forms. 
Some  of  the  conflicts  among  goals  disappear  with  radical  changes  in  per¬ 
spective,  Other  conflicts,  which  we  were  unable  to  so  eliminate,  can  be 
parameterized  so  that  the  user  and  not  the  language  designer  is  able  to  choose 
the  point  of  compromise. 

Four  main  ideas  emerged  from  these  considerations: 

a)  Data  is  of  primary  importance  and  should  be  designed 
first  with  the  care  usually  given  to  the  language  im¬ 
peratives. 

b)  Two-dimensional  representation  permits  humans  to  deal 
with  greater  complexity  than  is  possible  with  linear 
representations. 

c)  People  seem  to  have  an  ability  to  comprehend  spatial 
patterns  of  far  greater  complexity  than  temporal. 

d)  Redundant  information  in  the  form  of  constraints  can  be 
highly  useful  both  to  people  and  to  the  machine. 

How  is  it  that  these  ideas  have  been  overlooked  for  so  long?  To  some 
extent,  they  are  not  new.  LISP,  PL/I,  ALGOL  68  and  BASEL  certainly  have 
the  ability  to  deal  with  highly  structured  data.  SNOBOL  owes  much  of  its 
success  to  the  pattern-replacement  idea.  Certain  explicit  constraints  such  as 
declarations  of  array  sizes  and  data  type  are  present  in  several  languages. 

But  the  exciting  discovery  is  that  the  ideas  are  not  independent  and  cannot 
realize  their  full  potential  in  isolation. 

Many  languages,  as  we  have  noted,  can  deal  with  highly  structured 
data.  However,  few  languages  make  it  convenient  to  manipulate  data  which 
is  not  basically  tree -structured  (or  at  least  acyclic).  In  LISP,  for  example, 
one  can  create  arbitrary  structures  through  the  use  of  the  functions  RPLACA 
and  RPLACD,  but  it  is  an  exercise  reserved  for  the  expert. 
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An  important  reason  for  the  preference  for  hierarchial  data  is  that  it 
can  be  linearized  in  a  fairly  natural  way  using  parentheses,  precedence/  and 
other  devices.  But  these  methods  do  not  generalize  nicely  to  cyclic  structures, 
so  a  conceptual  barrier  arises  between  the  two  types  of  data.  The  net  result 
seems  to  be  that  users  are  encouraged  to  force  all  their  data  into  the  often 
inappropriate  hierarchial  mold.  In  two  dimensions,  however,  cyclic  graphs 
are  as  easily  represented  as  trees,  and  it  becomes  natural  to  break  away 
from  tree  structures  wherever  appropriate. 

Pattern-matching  gives  SNOBOL  a  gestalt  capability  and  in  many 
cases  results  in  surprisingly  perspicuous  programs.  However,  string  data 
tends  to  have  only  limited  sorts  of  interesting  patterns,  so  many  SNOBOL 
programs  use  the  pattern-matching  facility  mainly  to  emulate  the  structured 
data  found  in  other  languages.  By  generalizing  the  types  of  data  that  can  be 
manipulated,  many  more  interesting  types  of  patterns  become  manifest  and 
the  gestalt  methods  of  programming  can  handle  a  far  larger  portion  of  the 
computational  task. 

Designers  of  programming  languages  have  often  regarded  declarations 
as  nuisances  which  are  eliminated  wherever  possible  and  which  are  useful  only 
if  a  language  is  to  be  "compiled".  It  is  true  that  such  constraints  enable 
more  efficient  implementations  of  a  language,  but  they  also  serve  two  other 
distinct  and  equally  important  functions.  First,  they  greatly  facilitate  de¬ 
bugging  by  establishing  a  set  of  conditions  under  which  the  program  must 
operate;  any  attempted  violation  indicates  an  error.  The  subscript  bounds 
checking  of  PL/I  and  the  type-checking  of  ALGOL  are  such  conditions.  Second, 
declarations  of  constraint  are  a  reliable  form  of  comment  and  thus  help  con¬ 
tribute  to  documentation.  The  programmer  who  says  on  a  comment  card  that 
his  program  never  stores  a  number  bigger  than  100  into  the  variable  X  states 
this  as  a  matter  of  belief;  the  programmer  who  includes  that  statement  as  an 
explicit  constraint  knows  it  to  be  true  as  a  matter  of  fact.  The  significance 
of  this  distinction  cannot  be  overestimated  in  a  typical  program  which  is  modi¬ 
fied  many,  many  times  before  completion. 

While  constraints  can  be  extremely  valuable,  it  is  difficult  with  most 
programming  languages  to  envision  very  many  different  kinds  other  than  the 
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ones  alluded  to  above.  However,  once  data  with  complicated  and  dynamically 
changing  structure  is  introduced,  there  becomes  a  much  more  pressing 
need  for  constraints.  The  added  generality  provides  more  directions  in  which 
program  optimization  is  possible  and  necessary.  But  most  important,  con¬ 
straints,  together  with  the  two-dimensional  representation,  are  the  tools 
the  user  needs  to  control  the  greater  complexity  possible  with  the  more  general 
data. 

SPECIFIC  LANGUAGES 


AMBIT/G  has  been  implemented  several  times  in  the  past  four  years, 
and  these  implementations  are  listed  in  the  Project  Bibliography  included 
in  this  report.  Most  of  the  remainder  of  this  report  is  devoted  to  the 
most  recent  of  these  implementations,  an  AMBIT/G  system  on  Multlcs. 

We  have  already  stated  that  the  AMBIT/G  system  is  experimental  and 
is  a  vehicle  for  expressing  basic  ideas  about  programming.  On  one  hand, 
the  system  carries  the  use  of  diagrams  to  an  extraordinary  extreme,  includes 
very  carefully  developed  facilities  for  definition  and  use  of  functions,  and 
endows  the  data  with  unprecedented  independence.  On  the  other  hand,  we 
have  excluded  features  which  we  considered  to  be  trivial  (rational  arithmetic) , 
over-sophisticated  (block  structure),  or  peripheral  (graphic  input-output). 

The  resulting  programming  system  is  a  theoretical  model,  not  a  practical 
language  for  software  programming. 

The  AMBIT/G  language  described  in  this  report  is  the  most  important 
result  of  the  project.  It  is  the  basis  for  future  development  of  both  theory 
and  practice.  However,  a  very  different  language,  AMBIT/L,  has  come  to 
light,  rather  unexpectedly,  as  part  of  the  project. 

AMBIT/L  is  the  result  of  a  vigorous  specialization  and  simplification 
of  AMBIT/G  to  produce  a  practical  language  for  list-processing.  It  has 
an  applications  area  quite  similar  to  that  of  LISP,  but  it  uses  the  diagrammatic 
pattern-replacement  style  of  AMBIT/G.  The  language  is  described  in  a 
separate  paper  listed  in  the  bibliography  and  submitted  with  this  report. 

Under  auspices  other  than  this  project,  it  was  fully  implemented  and  then 
successfully  applied  to  the  construction  of  a  large  software  system  for 
interactive  algebraic  manipulation. 
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Thus  two  specific  languages  have  resulted  from  the  project:  AMBIT/G, 
an  adaptable  framework  for  testing  principles  of  language  design,  and 
AMBIT/L,  a  practical  embodiment  of  the  current  results  of  our  work  on 
diagrammatic  programming. 
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CHAPTER  3 


REPRESENTATION  OF  PROGRAMS 


The  diagrams  with  which  the  programmer  represents  his  program  are 
represented  in  the  AMBIT/G  system  as  ordinary  AMBIT/G  data  and  are  accessi¬ 
ble  to  him  in  the  same  manner  as  any  other  data.  This  allows  one  to  write 
programs  which  construct  other  programs  or  which  modify  themselves.  It  also 
permits  the  interpreter  itself  to  be  expressed  as  an  AMBIT/G  program,  which 
we  have  chosen  to  do  in  order  to  give  a  formal  desctiption  of  the  semantics  as 
well  as  being  an  aid  in  the  production  of  an  implementation.  The  interpreter 
and  the  implementation  are  described  elsewhere  in  this  report. 

OVERVIEW  OF  THE  PROGRAM  REPRESENTATION 


The  description  of  the  program  representation  is  in  two  parts.  First  we 
define  a  class  of  data  graphs  which  we  call  program  graphs  and  which  consti¬ 
tute  the  class  of  legal  inputs  to  the  interpreter.  Second,  we  attempt  to  show 
how  to  find  a  diagram  which  the  program  graph  represents.  We  note  that  there 
is  not  a  one-to-one  correspondence  between  program  graphs  and  diagrams;  a 
given  diagram  may  be  represented  by  many  different  program  graphs  and  con¬ 
versely,  many  different  diagrams  may  have  the  same  program  graph  for  their 
representation  (e.g.  diagrams  which  differ  only  in  the  positions  of  the  nodes 
on  the  page) . 

Two  diagrams  with  the  same  set  of  possible  representations  are  se¬ 
mantically  equivalent.  However,  we  will  see  that  it  is  possible  for  a  diagram 
to  be  represented  by  two  or  more  distinct  program  graphs  upon  which  the  in¬ 
terpreter  will  behave  differently  and  perhaps  produce  differing  results.  This 
may  occur,  for  example,  when  a  rule  contains  calls  on  functions  which  have 
side-effects.  Diagrams  which  lead  to  two  or  more  inconsistent  interpretations, 
even  though  syntactically  correct,  are  considered  to  be  semantically  undefined 
and  not  a  part  of  the  AMBIT/G  language. 
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Briefly,  a  rule  is  represented  by  a  collection  of  nodes  of  a  small 
number  of  pre-deflned  types  and  certain  of  their  links.  The  nodes  in  general 
represent  the  pieces  of  the  diagram  such  as  the  boxes  and  the  arrows, while 
the  links  represent  the  relationships  among  the  pieces. 

These  same  nodes  carry  other  links  which  are  used  to  record  mis¬ 
cellaneous  information  generated  during  the  process  of  execution  of  the  pro¬ 
gram.  Such  information  Includes  the  results  of  compilation  of  a  rule,  the  calls 
on  user  functions  which  are  currently  active,  and  the  arguments  and  results 
being  passed  to  user  functions .  Further  mention  of  these  links  is  deferred  to 
the  chapter  on  the  interpreter. 

PROGRAM  SYNTAX 

Shapes  and  Links  in  the  Representation 

A  program  graph  is  a  collection  of  nodes  of  the  pre-deflned  types 
'rule',  'llnkrep',  'noderep',  'diamond',  and  'flag',  called  program  repre¬ 
sentation  nodes,  together  with  the  links  shown  in  the  table  below.  The  . 
shapes  used  to  picture  these  node  types  and  the  relevant  links  are  shown 
following  the  table. 
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Links  defined  for  a  rule  In  state  'clear* 


Node 

Type 

rule 

Link 

success 

fall 

contents 

Destination 

rule 

rule 

linkrep 

Meaning 

success  exit. 

fall  exit. 

encoding  of  rule 

contents . 

linkrep 

mode 

flag 

mode  of  the  link 

('frame',  'test'  or 
'modify'). 

org 

diamond 

list  of  tails. 

name 

noderep 

link  name. 

dest 

diamond 

list  of  heads. 

next 

linkrep 

used  to  form  list. 

diamond 

next 

diamond 

next  element  in 

heads  or  tails  list. 

value 

noderep 

the  list  element 

Itself. 

noderep 

variability 

flag 

tells  whether  or  not 

the  node  is  a  dummy. 

rep* 

user  node 

the  node  of  the  data 

graph  represented  by 

this  rule  node. 

•Defined  only  if  the  'variability'  link  points  to  'flag  fixed'. 
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The  syntax  of  AMBIT/G  is  specified  by  a  "grammar"  consisting  of 
special  diagrams.  As  in  BNF,  we  introduce  meta-iinguistic  variables  which 
we  call  property  symbols  and  represent  by  hexagons  containing  a  character 
string.  However,  unlike  BNF,  we  do  not  think  of  our  grammar  as  generating 
a  graph  but  rather  as  a  means  of  testing  a  graph  for  certain  well-formedness 
properties.  Given  a  data  graph,  our  grammar  rules  allow  us  to  assign  one  or 
more  properties  to  certain  nodes  of  the  graph.  A  hexagon  from  which  emanates 
a  double  arrow  is  a  defining  instance  of  that  property.  A  given  node  of  the 
data  graph  is  defined  to  have  that  property  if  the  pattern  beginning  at  the 
destination  of  the  double  arrow  can  be  matched  to  a  subgraph  of  the  data 
beginning  with  the  given  node.  For  example,  the  syntax  rule 


says  that  every  node  of  type  'cell'  has  the  property  'foo',  whereas  the  rule 


goo 
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says  max  omy  ceil  s  wnuoe  auwn  uiw  (wims  wo  nuuc  u* 
have  property  'goo' . 

A  property  symbol  may  be  used  to  qualify  other  nodes  appearing  in 
the  diagram.  For  example,  the  rule 


says  that  a  'cell'  has  the  property  'hoo'  providing  that  its  'down'  link  points 
to  a  node  with  property  'goo' .  This  may  be  abbreviated  as 


Two  other  notations  may  be  employed  in  writing  syntax  rules,  A 
section  of  the  pattern  may  be  enclosed  in  a  dotted  box  to  indicate  zero  or 
more  repetitions  of  the  enclosed  pattern.  For  example, 
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specifies  that  a  'cell1  is  a  'list'  if  either  it  is  the  node  'cell  end1  or  if 
'cell  end'  can  be  reached  from  it  via  a  chain  of  'cell's  along  the  'next'  link. 

Finally,  we  allow  an  arrow  of  the  pattern  to  branch,  meaning  an  al¬ 
ternative  is  allowed.  For  example. 


terminator 


means  that  a  'cell'  is  a  'terminator'  if  its  'next'  link  points  either  to 
'cell  end'  or  to  an  'atom' . 


The  Syntax  of  AMBIT/G 

A  collection  of  program  representation  nodes  is  by  definition  a  pro¬ 
gram  if  some  'rule'  node  in  the  collection  is  assigned  the  property  'rule' 
by  the  following  grammar.  Any  node  with  that  property  is  a  valid  place  at 
which  to  begin  execution . 
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Grammar  for  AM  BIT /G 


llnklist 


Additional  Restrictions 


In  addition  to  the  restrictions  imposed  by  the  grammar  above ,  we 
constrain  the  “sharing"  that  may  take  place  among  nodes.  Informally,  we 
require  that  no  node  "belong"  to  the  representation  of  more  than  one  link. 

More  formally,  we  say  that  a  'diamond'  D  belongs  to  the  'org'  ('dest') 
list  of  a  'linkrep'  L  if  D  is  not  the  node  'diamond  end'  and  also  D  is  accessible 
from  L  by  a  path  beginning  with  an  'org'  ('dest')  link  from  L  and  then  continuing 
with  zero  or  more  'next'  links  from  'diamonds'. 

We  say  that  a  node  N  belongs  to  a  'rule'  node  R  if  either: 

a)  N  is  not  the  node  'linkrep  end'  and  N  is  accessible  from 
R  by  a  path  beginning  with  the  'contents'  link  of  R  and 
continuing  with  zero  or  more  'next'  links  from  'linkrep' 
nodes;  or 

b)  N  is  a  'diamond'  which  belongs  to  the  'org'  or  'dest'  list 
of  some  'linkrep'  node  which  belongs  to  R;  or 

c)  N  is  a  'noderep'  node  which  is  the  destination  of  the 
'value'  link  of  some  'diamond'  which  belongs  to  R;  or 

d)  N  is  a  'noderep'  node  which  is  the  destination  of  the 
'name'  iink  of  some  'linkrep'  node  which  belongs  to  R. 

We  then  require  that  each  'linkrep',  'diamond'  and  'noderep'  node 
belongs  to  at  most  one  rule,  and  in  addition,  each  'diamond'  belongs  to  the 
'org'  or  'dest'  list  (but  not  to  both)  of  one  'linkrep'  node. 

CORRESPONDENCE  BETWEEN  PROGRAM  GRAPHS  AND  DIAGRAMS 

In  this  section,  we  show  how,  given  a  program  graph,  to  find  a 
diagram  which  that  graph  represents. 

A  'rule'  node  together  with  the  nodes  which  belong  to  it  represent  a 
single  rule,  diagrammed  by  a  rule  box.  The  suoname  of  the  'rule'  node  is 
written  in  the  upper-left  comer  of  the  rule  box.  The  success  and  fail 
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exits  of  the  rule  lead  to  those  rule  boxes  represented  by  the  destinations 
of  the  'success'  and  'fail'  links  respectively. 

Each  'noderep'  node  belonging  to  the  rule  corresponds  to  a  node 
box  in  the  rule.  A  dummy  'noderep'  (i.e. ,  one  whose  'variability'  link 
points  to  'flag  dummy')  is  represented  by  a  node  box  with  no  contents.  A 
fixed  'noderep'  whose  'rep'  link  points  to  a  named  node  corresponds  to  a 
node  box  containing  the  full  node  name.  At  present,  we  have  no  way  to 
diagram  a  fixed  'noderep'  whose  'rep'  link  points  to  an  unnamed  node. 

Each  'linkrep'  node  corresponds  to  an  arrow  of  mode  specified  by 
the  'mode'  link.  The  number  of  heads  and  tails  of  this  arrow  are  determined 
by  the  lengths  of  the  lists  of  diamonds  hanging  on  the  'dest'  and  'org'  links 
respectively.  The  'tails'  and  'heads'  of  this  arrow  are  attached  to  the  node 
boxes  corresponding  to  the  'noderep'  nodes  which  are  the  destinations  of 
the  'value'  links  of  the  'diamond's  in  the  'org'  and  'dest'  lists  respectively. 
The  spur  of  this  arrow  is  the  node  box  corresponding  to  the  'noderep'  node 
at  the  destination  of  the  'name'  link. 


An  example  should  help  to  make  these  ideas  clear. 


Examp) o  of  Ruin  Representation 


Sugared  form  of  rule: 


Desugared  form  of  rule: 


28 


Data  representation  of  rulo: 


CHAPTER  4 


THE  INTERPRETER 


The  AMBIT/G  interpreter  Is  an  agent  which,  given  an  AMBIT/G  data 
graph  and  the  starting  rule  of  a  program  represented  within  that  graph,  modi¬ 
fies  the  graph  in  successive  steps  according  to  one  of  the  many  possible 
Interpretations  of  the  AMBIT/G  language. 

Not  all  AMBIT/G  programs  will  produce  the  same  results  on  all  Imple¬ 
mentations  of  the  language;  such  programs  we  consider  to  be  ill-formed.  The 
decision  to  admit  the  possibility  of  certain  syntactically  correct  programs  whose 
semantics  are  unspecified  is  a  compromise  at  best.  It  has  the  obvious  disad¬ 
vantage  that  it  may  be  difficult  or  Impossible  to  determine  mechanically 
whether  a  given  program  is  ill-formed,  so  that  one  may  unwittingly  use  an 
illegal  program  to  produce  correct  results  at  one  installation  and  later  have  it 
fail  at  another. 

On  the  other  hand,  to  attempt  to  specify  completely  the  effects  of  ex¬ 
ecution  of  all  syntactically  correct  programs  severely  restricts  the  range  of 
possible  implementations  at  perhaps  a  considerable  cost  of  efficiency.  More 
seriously,  one  is  forced  to  define  and  describe  the  results  of  "tricky"  or 
pathological  programs  which  should  not  be  written  anyway,  greatly  complicating 
tne  definition  of  the  language. 

Ours  is  not  a  new  approach.  FORTRAN  for  example  does  not  specify  the 
value  of  a  DO-variable  after  normal  exit  from  a  loop.  PL/I  likewise  has  many 
" implementation-dependent"  parameters . 

OVERVIEW  OF  THE  INTERPRETER 

This  section  gives  an  informal  description  of  the  operation  of  the  inter¬ 
preter.  It  presupposes  the  reader  is  familiar  with  the  representation  of  programs. 
It  also  uses  the  notation  for  describing  paths  through  the  graph  that  is  defined 
in  the  chapter  on  the  AMBIT/G  symbolic  debugger.  While  some  attempt  was 
made  to  be  complete,  this  section  should  be  regarded  principally  as  an  introduc¬ 
tion  to  the  formal  definition  of  AMBIT/G. 
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The  interpreter  operates  on  a  rule  by  rule  basis,  going  through  a 
cycle  of  several  phases  for  each  rule. 

Most  of  the  information  recording  the  progress  of  execution  of  the 
program  is  stored  in  the  several  links  originating  from  the  'rule'  and  'noderep' 
nodes  which  represent  the  program;  hence  this  information  is  available  dy¬ 
namically  for  inspection  and  modification. 

Each  'rule'  node  has  a  'state'  link  which  tells  the  current  status  of 
execution  of  that  rule.  State  'clear'  indicates  a  rule  ready  to  be  executed 
for  the  first  time.  Such  a  rule  must  first  be  compiled,  after  which  its  state 
is  set  to  'compiled' . 

Execution  then  proceeds  through  the  rule  in  three  phases:  'frame', 

'test',  and  'modify',  as  Indicated  by  the  'state'  link.  In  each  phase,  'linkrep's 
of  the  corresponding  mode  are  examined  one  at  a  time  in  the  order  specified  by 
the  compiler  and  the  appropriate  action  is  taken,  'linkrep's  of  mode  'frame' 
cause  dummy  nodes  to  be  matched  (bound)  to  nodes  of  the  data  graph;  those  of 
mode  'test'  cause  the  destinations  of  links  to  be  tested,  and  those  of  mode 
'modify '  cause  links  in  the  data  graph  to  be  altered. 

If  any  of  the  tests  fail,  the  rule  fails  immediately  —  the  remainder  of 
the  'test'  phase  and  the  entire  'modify'  phase  are  then  skipped,  and  the  inter¬ 
preter  proceeds  to  the  rule  specified  by  the  'fail'  link.  If  all  the  tests  succeed 
then  the  'modify'  phase  is  performed  as  described,  after  which  another  interpre¬ 
tation  cycle  begins  with  the  rule  at  the  destination  of  the  'success'  link.  In 
either  case,  the  state  of  the  rule  lust  executed  is  set  back  to  'compiled'  to 
indicate  that  compilation  need  not  be  repeated  on  subsequent  executions  of  that 
rule.  Of  course,  if  a  user  modifies  a  rule,  he  should  reset  the  'state'  link  to 
'flag  clear'  which  indicates  that  rule  is  in  the  'clear'  state. 

Two  rules  have  a  special  interpretation  associated  with  them; 

'rule  error'  causes  an  error  message  to  be  emitted  and  execution  to  terminate; 
'rule  stop'  causes  a  normal  return  from  the  currently  executing  user  subroutine, 
or  if  at  the  top  level,  a  normal  program  stop.  For  both  of  these  rules,  the 
action  is  taken  immediately  and  any  contents  of  the  rule  are  Ignored. 
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THE  COMPILER 


The  compiler  is  not  invoked  until  just  before  a  rule  is  to  be  executed, 
and  on  each  call,  it  compiles  only  the  single  rule  which  is  its  argument. 

Compilation  consists  of  sorting  the  'linkrep's  by  mode  and  ordering 
those  of  mode  'frame'  so  that  later  during  interpretation  every  dummy  node  of 
the  rule  will  have  been  bound  to  a  node  of  the  data  graph  before  it  is  referenced. 
The  compiler  reports  an  error  if  such  an  ordering  is  not  possible. 

Compilation  does  not  modify  any  of  the  links  originally  used  to  repre¬ 
sent  the  rule.  Rather,  it  adds  information  to  the  representation  of  the  rule  by 
setting  additional  links  on  the  nodes  of  type  'rule',  'linkrep',  and  'noderep', 
as  shown  in  the  following  table: 


Additional  links  defined  for  a  rule  in  state  'compiled' 


Node 

tyge 

Link 

Destination 

Meaning 

rule 

frame 

linkrep 

Head  of  a  properly  ordered  list 
of  the  'linkrep's  of  mode  'frame 

test 

linkrep 

Head  of  a  list  of  the  'linkrep's  of 
mode  'test'. 

modify 

linkrep 

Head  of  a  list  of  the  'linkrep's  of 
mode  'modify'. 

linkrep 

nextl 

linkrep 

Used  to  chain  together  the  ele¬ 
ments  of  the  'frame',  'test', 
and  'modify'  lists. 

noderep 

sets 

diamond 

If  the  node  is  a  'dummy',  points 
to  the  'diamond'  in  the  'frame' 
list  which  will  bind  the  'rep' 
link  during  execution.  If  the 
node  is  'fixed',  it  points  to 
'diamond  matched'. 
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The  'frame'  ,  'test'  /  and  'modify'  links  of  the  'rule'  node  are  set  to  point  to 
the  three  new  lists  of  'linkrep's  which  the  compiler  creates  using  the  'nextl' 
link  of  the  'linkrep's.  In  addition,  the  compiler  sets  the  'sets'  link  of  each 
'noderep'  to  point  to  the  'diamond'  of  the  'linkrep'  which  is  supposed  to  bind 
it,  if  any.  (All  the  other  'frame'  links  which  locate  the  node  should  just 
verify  the  prior  setting.) 

The  compilation  algorithm. is  fairly  simple.  First,  all  of  the  'noderep' 
nodes  belonging  to  the  rule  are  marked  as  matched  or  unmatched  according  to 
whether  they  are  fixed  or  dummies.  The  'sets'  link  is  temporarily  used  for 
this  purpose.  At  the  same  time,  the  'linkrep's  are  chained  together  in  one 
big  list,  called  the  active  list,  temporarily  using  the  'nextl'  link. 

The  active  list  is  then  scanned  for  an  entry  which  is  eligible  for 
processing.  An  entry  is  eligible  if  the  'noderep's  hanging  from  its  'org'  and 
'name'  links  have  ali  been  previously  matched  and,  in  the  case  of  'test'  and 
'modify'  'linkrep's,  the  destination  'noderep's  have  been  matched  as  well. 
Whenever  such  an  entry  is  found,  it  is  removed  from  the  active  list  and  pro¬ 
cessed.  The  active  list  is  then  rescanned.  When  a  complete  pass  over  the 
active  list  fails  to  locate  an  eligible  entry,  the  scanning  phase  terminates. 

The  processing  of  a  'linkrep'  depends  on  its  mode,  'test'  and  'modify' 
'linkrep's  are  processed  simply  by  placing  them  at  the  ends  of  the  'test'  and 
'modify'  lists  respectively,  'frame'  'linkrep's  are  likewise  placed  on  their 
respective  list,  but  in  addition,  any  destination  'noderep's  are  marked  as 
being  'matched',  possibly  making  additional  'linkrep's  eligible  for  processing. 

At  the  termination  of  the  scanning  phase,  a  non-empty  active  list  Indi¬ 
cates  an  error,  for  the  rule  then  must  contain  a  node  that  cannot  be  matched. 

If  there  has  been  no  error,  the  three  new  lists  of  'linkrep's  are  then  attached 
to  their  respective  points  on  the  'rule'  node  ard  compilation  of  the  rule  is 
complete . 

In  response  to  a  successful  compilation,  the  interpreter  changes  the 
state  from  'clear'  to  'compiled'. 
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Below  is  on  a  ug  men  Lit  ion  of  the  syntax  of  AMBIT/G  to  describe  compiled 


rules . 
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modify 


THE  INTERPRETATION  OF  'linkrep's 


Each  'linkrep'  appearing  In  a  rule  denotes  an  elementary  action 
which  is  either  a  call  on  a  user-defined  function  or  the  execution  of  a 
primitive  operation.  Which  action  is  actually  taken  by  the  interpreter  when 
it  encounters  the  'linkrep'  L  is  determined  dynamically  and  depends  on: 

a)  the  mode  of  L; 

b)  the  number  of  arguments  of  L; 

c)  the  types  of  the  arguments  of  L;  and 

d)  the  f-name  of  L. 


The  mode  of  L  is  the  destination  of  its  'mode'  link  and  is  either 
'flag  frame',  'flag  test'  or  'flag  modify'.  The  arguments  of  L  are  those  nodes 
of  the  user's  data  which  are  matched  to  'noderep'  nodes  hanging  off  the 
'org'  link  of  L  (see  Figure  4-1).  The  f-n  ime  of  L  is  the  node  'L/name/rep/ ' 
(see  Figure  4-2). 


Figure  4-1:  Arguments  of  L 
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f-namo  : 


Figure  4-2:  The  {-name  of  L. 


The  mode  of  L  determines  the  class  of  the  action  to  be  taken:  modes 
'frame'  and  'test'  result  in  a  class  read  action,  while  mode  'modify'  signifies 
a  class  write  action.  Basically,  a  read  action  is  taken  to  obtain  one  or  more 
values  and  is  the  generalization  of  reading  a  link.  A  write  action  returns  no 
values  and  is  executed  solely  for  its  side  effects;  it  generalizes  link  writing. 

For  a  'linkrep'  L  of  class  read  (write),  a  call  is  made  by  the  interpreter 
on  the  primitive  function  're.td_function'  fwrite_function')  with  the  f-name 
and  list  of  argument  types  as  parameters.  This  primitive  returns  a  node  of 
type  either  'rule'  or  'builtin'.  If  the  node  is  of  type  'rule',  the  interpreter  then 
makes  a  class  read(class  write)  call  on  a  user  function  with  execution  beginning 
with  that  rule.  Otherwise,  the  interpreter  performs  the  action  corresponding  to 
that  'builtin'  and  class  read  (write).  In  most  cases,  this  action  is  simply  to 
pass  the  arguments  (and  sometimes  other  information)  to  the  corresponding 
primitive  routine. 
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l’or  a  class  write  action,  there  is  nothing  more  to  do.  However,  a 
class  road  operation  returns  one  or  more  results.  These  results  are  then 
us-'  d  by  1  ho  interpreter  either  to  set  or  to  test  the  value  of  the  'rep'  link  of 
the  'nodorep's  hanging  off  of  the  ‘dest’  link  of  L.  In  mode  'test',  equality 
must  hold  between  corresponding  results  and  'rep'  links  or  else  the  rule 
fails.  In  mode  'frame',  a  given  result  may  be  used  either  to  set  the  'rep' 
link  or  to  verify  a  prior  setting.  Which  of  the  two  occurs  depends  on  the 
setting  of  the  'sets'  link  of  the  particular  'nodcrep'.  If  it  points  back  to  the 
'diamond'  through  which  it  was  located,  then  a  setting  action  takes  place 
(see  Tigurc  4-3  )  ;  otherwise,  a  verification  occurs  (see  Figure  4-4  ).  An 
inequality  in  the  verification  indicates  an  error  which  the  interpreter  then 
reports . 


Figure  4-3  :  Conditions  for  the  setting  oi 
the  'rep'  link. 
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Figure  4-4;  Conditions  for  the  verification 
of  the  'rep'  link. 


USER-DEFINED  FUNCTIONS 


There  are  three  parts  to  a  user-defined  function:  the  definition,  the 
call,  and  the  return. 

Function  Definitions 


A  user  function  is  defined  by  associating  a  'rule'  node  with  a  particular 
call-class  (i.e.  read  or  write),  f-name,  and  argument-type  list.  This  Is  per¬ 
formed  by  a  class  write  call  on  the  primitive  'read_function'  to  define  a  class 
read  call,  or  on  'write_function'  to  define  a  class  write  call. 

AM  BIT/ G  does  mt  have  any  sort  of  block  structure,  and  there  is  no 
well-defined  collection  of  rules  which  can  be  called  the  "body"  of  the  function. 
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Rather,  a  given  rule  can  be  shared  by  any  number  of  functions;  this  permits 
multiple-entry  functions  as  a  special  case. 


Function  Calls 


Once  the  Interpreter  determines  that  a  user  function  is  to  be  called , 
it  performs  the  following  set  of  actions: 


a)  It  sets  up  'pipe's  on  the  'rule'  node  of  the 
caller  for  the  transmission  of  values  between 

the  caller  and  the  function; 

b)  It  sets  'ptr  next__rule/value'  to  the  starting  rule 
of  the  function  to  be  called; 

c)  It  saves  its  current  status  on  the  'rule'  node  of 
the  caller; 

d)  It  sets  'ptr  ret/value'  to  point  to  the  'rule'  node 
of  the  caller,  thus  enabling  the  function  to  lo¬ 
cate  the  call;  and 

e)  It  begins  Interpreting  'rule  go'. 


Thus,  all  of  the  information  relevant  to  the  call  is  saved  with  the  caller.  The 
actual  links  used  are  shown  below  and  summarized  in  the  table  which  follows* 
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Links 

used  In  calling  user 

functions 

Node 

type 

Link 

Destination 

Meaning 

rule 

tails 

pipe 

List  of  'pipe's  which  contain  the 
actual  tail  arguments  to  the  user 
function  c?illed  from  within  this  rule  . 

spur 

user  node 

The  actual  link  name  that  caused 
the  user  function  to  be  Invoked. 

heads 

pipe 

List  of  'pipe's  which  contain  the 
actual  head  arguments  or  which 
will  receive  the  results  of  the  user 
function  called  from  within  this 
rule,  depending  on  the  class  of 
the  call. 

state 

flag 

The  mode  of  the  link  causing  the 
call  on  the  user  function. 

savel 

Unkrep 

The  actual  link  representation  that 
caused  the  call. 

save  ret 

rule 

Used  to  save  the  old  value  of 
'ptr  ret/value' . 
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The  arguments  passed  to  the  function  depend  on  the  class  of  the  call, 
whether  road  or  write.  In  either  case,  tho  interpreter  builds  two  lists  of  'pipe's 
equal  in  length  to  the  'org'  and  'dost'  lists  of  'diamond's  on  the  calling  'Unkrep'. 
The  actual  origin  arguments  arc  then  copied  into  the  'value'  links  of  the  'tails' 
pipe's.  1’or  a  class  write  call,  the  actual  destination  arguments  are  similarly 
copied  into  the  'value'  links  of  the  'heads'  'pipe's,  but  for  a  class  read  call, 
those  links  are  Instead  set  to  undefined  (the  node  'undo!  undef).  In  olther 
case,  the  f-namo  which  caused  the  function  to  be  invoked  is  stored  as  the  des¬ 
tination  of  the  'spur'  lln'»;  of  the  'rule'  node  of  the  caller,  sometimes  useful  when 
the  same  code  is  to  be  used  to  implement  several  slightly  different  but  similar 
functions. 

The  interpreter  docs  not  go  directly  to  the  desired  function;  rather,  all 
function  calls  lead  to  'rule  go'  which  has  a  default  definition  which  causes  an 
immediate  branch  to  the  function.  The  reason  for  this  indirection  is  to  enable 
the  user  to  extend  or  modify  the  action  taken  by  the  interpreter  on  a  function 
call,  for  the  user  need  only  replace  the  default  contents  of  'rule  go'  with  his 
own.  It  is  to  be  emphasized  that  'rule  go'  exists  in  the  user's  data  base  and 
is  interpreted  in  just  the  same  way  as  any  other  user  rule.  An  example  of  an 
extension  requiring  modification  of  'rule  go'  is  the  recursion  package  which 
extends  the  interpreter  to  handle  recursive  procedures.  The  reader  is  referred 
to  the  'factorial'  example  for  more  details  on  this  (at  the  end  of  Volume  II). 

The  status  that  is  saved  consists  of  the  state  of  the  interpreter  (whether 
'frame',  'test',  or  'modify'),  tho  current  'linkrep'  (the  one  causing  the  call), 
and  the  old  value  of  ptr  ret'.  This  information  is  saved  on  the  links  'state', 
'savel',  and  'saveret'  respectively. 

The  ordinary  AMBIT AJ  programmer  may  ignore  most  of  the  above  details. 
He  only  needs  to  know  that  for  a  class  read  function,  the  arguments  are  to  be 
found  in  the  list  of  pipe's  located  by  'ptr  ret/value/tails’  and  that  the  results 
to  bo  returned  by  the  function  should  be  stored  in  the  'pipe's  located  by 
•ptr  ret/volue/heads'.  Similarly,  for  a  class  write  function,  both 
'ptr  rei/volue/talls’  and  'ptr  ret/value/hcads*  contain  arguments. 
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Function  Returns 


To  return  from  a  function,  It  suffices  to  branch  to  'rule  stop',  but 
the  programmer  Is  instructed  to  branch  always  to  'rule  ret',  which  has  a 
default  definition  of  always  branching  immediately  to  'rule  stop'.  In  this 
way,  a  modification  of  'rule  ret'  will  allow  function  returns  to  be  Intercepted 
much  In  the  same  way  as  function  calls  can  be  monitored  by  altering  'rule  go'. 

When  the  Interpreter  Interprets  'rule  stop',  it  performs  almost  an  exact 
Inverse  of  the  five  steps  involved  in  a  function  call  by  doing  the  following: 

a)  It  turns  Its  attention  to  the  rule  located  by 
'ptr  ret/value'  and  halts  if  that  value  also 
happens  to  be  'rule  stop'; 

b)  It  restores  the  previous  setting  of  'ptr  ret/value' 
from  the  'saveret'  link; 

c)  It  restores  Its  previous  status  from  the  'state' 
and  'savel'  links; 

d)  It  processes  any  results  produced  by  the 
function  and  frees  the  pipe's  for  later  use;  end 

e)  It  continues  with  the  Interpretation  of  the  rule. 


Recursion  Faults 

During  the  execution  of  a  function  a  rule  may  be  encountered  whose 
state  is  'frame',  'test',  or  'modify',  indicating  that  the  rule  Is  currently 
suspended  because  it  contains  a  function  call  which  is  now  being  processed. 

This  can  occur  only  as  a  result  of  an  attempted  recursive  function  call.  In 
this  case,  the  interpreter  does  not  try  to  execute  the  rule  but  rather  points 
'ptr  nextjrule/value'  at  It  and  then  branches  to  'rule  help'.  AMBIT/G  does 
not  support  recursion,  so  'rule  help'  normally  branches  immediately  to  'rule  error'. 
However,  the  user  may  supply  his  own  version  of  'rule  help'  to  save 
the  important  information  of  the  rule  about  to  be  executed,  reset  Its  state  to 
'compiled',  and  then  branch  to  It.  This  Is  the  final  handle  needed  by  the  re* 
curs  ion  package. 
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ERROR  MESSAGES  Or  THE  AM BIT/'G  INTERPRETER 


Tho  following  is  a  list  of  the  various  error  messages  which  may  be 
typed  out  as  a  result  of  tho  interpreter's  detecting  an  error  condition.  The 
use  of  three  periods  is  to  indicate  a  symbolic  node  name  will  be  typed 
according  to  the  state  of  the  data. 

1.  System  imple  icntation  error  in  the  interpreter  probably  due  to 
improper  data;  a  frame  does  not  match  because  "  ...  "  is  not 
the  same  as 

2.  System  implementation  error  in  the  interpreter  probably  due  to 
improper  data;  a  frame  does  not  match  because  a  link  with  origin 

. . .  and  name  "  ..."  points  to  destination  "  ..."  Instead 

*  c  ||  II 

OI  . 

3.  System  implementation  error  in  the  Interpreter  probably  due  to 

improper  data;  a  frame  does  not  match  because  "  . . . "  is  not  of 
type  "  . . .  "  . 

4.  System  implementation  error  in  the  interpreter  due  to  an  over¬ 
sight  by  the  implementor;  a  rule  took  an  unexpected  fall  exit. 

5.  The  interpreter  is  attempting  to  interpret  a  non-rule. 

6.  The  interpreter  is  reporting  a  user-detected  error. 

7.  The  interpreter  is  attempting  to  Interpret  the  rule  -  .. ."  which 

is  in  an  unknown  state  of  "  ..."  . 
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8.  The  Interpreter  is  attempting  to  resume  the  interpretation  of 
rule  "  ..."  which  is  in  an  unknown  state  of  "  ..."  . 


9.  The  interpreter  has  detected  an  attempt  to  execute  an  undefined 
reading  function. 

10.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-call  on  the  builtin  "link". 

11.  The  Interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-call  on  the  builtin  "type". 

12.  The  Interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-call  on  the  builtin  "read_functior.'  . 

13.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-call  on  the  builtin  "write^function"  . 

14.  The  Interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-call  on  the  builtin  "name"  . 

15.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-call  on  the  builtin  "link' "  . 

16.  The  Interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-call  on  the  builtin  "char"  . 

17.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-cah  on  the  builtin  "locate”  . 

18.  The  Interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-call  on  the  builtin  "  load"  . 
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19.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-call  on  the  builtin  "add"  . 

20.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-call  on  the  builtin  "subtract"  . 

21.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-call  on  the  builtin  "multiply"  . 

22.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-call  on  the  builtin  "divide"  . 

23.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  read-call  on  the  builtin  "sign"  . 

24.  The  interpreter  has  detected  that  the  frame  is  inconsistent  with 
the  data  graph. 

25.  The  interpreter  has  detected  an  attempt  to  execute  an  undefined 
writing  function. 

26.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  write-call  on  the  builtin  "  link"  . 

27.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  write-call  on  the  builtin  "readjfunction"  . 

28.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  write-call  on  the  builtin  "write_function"  . 

29.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  write-call  on  the  builtin  "link'  "  . 

30.  The  interpreter  has  detected  a  wrong  number  of  tails  or  heads  on 
a  write-call  on  the  builtin  "char"  . 
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31.  The  interpreter  has  detected  the  "success"  exit  from  a  rule  leads 
to  "  ...  "  ,  which  is  not  a  rule. 

32.  The  interpreter  has  detected  the  "fail"  exit  from  a  rule  leads  to 
"  ...  ",  which  is  not.  a  rule. 

33.  The  interpreter  has  detected  a  wrong  number  of  results  returned 
by  a  user  function . 

34.  The  compilation  phase  of  the  interpreter  has  detected  the  mode  of 
a  link  is  "  ..."  ,  which  is  neither  flag  frame",  "flag  test",  nor 
"flag  modify" . 

35.  The  compilation  phase  of  the  interpreter  has  detected  that  a  rule 
contains  an  unreachable  node . 

36.  The  compilation  phase  of  the  interpreter  has  detected  that  the 

destination  of  a  "variability"  link  is  "  ,  which  is  neither 

"flag  fixed"  nor  "flag  dummy"  . 

37.  System  implementation  error  in  the  interpreter  or  loader  probably 
due  to  improper  data;  a  frame  does  not  match  because  a  link  with 
origin  "  ...  "and  name  "  ...  "  points  to  destination  "  ...  ",  which 
is  not  of  type  "  ...  "  . 
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CHAPTER  !> 


THE  LOA1  A  ,{ 


The  AMBlf/(J  louder  is  celled  as  a  built-in  reed  function  as  in 
the  following  sample  rule: 


Although  all  other  built-in  functions  are  defined  in  English,  the  loader 
was  written  as  an  AMBIT/G  program,  and  thus  its  listing  serves  as  a 
precise  definition  of  its  characteristics.  However,  we  shah  describe 
in  this  chapter  its  characteristics  from  a  user  or  programmer  viewpoint. 

Volume  IV  of  this  report  contains  a  description  of  the  loader  as  an 
AMBIT/G  program.  A  programmer  may  wish  to  study  the  loader  as  an 
example  of  a  large  AMBIT/G  program,  but  studying  the  AMBIT/G  Interpreter 
would  also  serve  this  purpose,  and  is  probably  more  useful. 

There  is  no  Important  reason  for  the  loader's  being  built-in  other 
than  convenience  and  efficiency  and  the  bootstrap  problem  of  how  to  load 
anything  (the  loader  itself).  As  a  function,  however,  the  loader  uses  no  more 
facilities  than  any  AMBIT/G  user  function.  A  similar  statement  cannot  be 
made,  of  course,  for  other  built-in  functions  such  as  the  primitives  to  read 
and  write  links.  As  the  system  exists,  however,  the  loader  is  known  to  the 
-Interpreter  as  a  primitive  and  is  also  known  to  the  system  in  the  way  in  which 
Initialization  leads  to  the  start  of  execution.  Namely,  tho  initializer  calls 
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upon  the  interpreter  with  an  argument  of  'rule  start'  shown  as  a  sample  rule 
above.  That  rule  is  interpreted  (and  compiled);  this  amounts  to  an  automatic 
call  on  the  loader.  Not*  how  'rule  start'  includes  a  modification  link  which 
causes  the  modification  of  its  own  'success'  exit  after  loading  to  the  first 
rule  of  the  loaded  program  (or  data) . 


OVERVIEW  OF  THE  LOADER 


The  loader  is  called  as  a  function  with  no  arguments  and  one  result. 
That  result  is  a  rule  node  which  is  meant  to  be  the  starting  rule  of  the  user's 
program.  If  the  loader  is  called  other  than  by  an  interpretation  of  'rule  start' 
the  result  may  be  used  or  not  according  to  the  programmer's  fancy. 

The  loader  reads  source  input  one  character  at  a  time  from  the  source 
file  (e.g.,  'foo.ambitg')  by  making  read  calls  on  the  built-in  function  'char' . 
It  analyzes  its  input  one  statement  at  a  time.  Normally,  a  statement  corre¬ 
sponds  to  one  input  line;  however,  many  statements  may  be  included  on  one 
line  by  using  semicolons,  and  there  is  a  method  for  continuing  any  statement 
across  any  number  of  input  lines. 

As  dictated  by  the  statements  it  reads,  the  loader  deals  with  one  en¬ 
coded  page  at  a  time.  We  consider  the  true  input  to  the  loader  to  be  pages 
of  diagrams.  Each  page  is  hand-translated  from  these  diagrams  into  several 
statements  which  represent  the  diagrams ,  but  do  not  include  coordinate 
(position)  infonnation.  Just  those  aspects  of  connectivity  which  are  essen¬ 
tial  to  the  AMBIT/G  meaning  of  the  page  are  encoded. 

As  the  loader  processes  a  page,  it  does  not  create  any  data.  Recall 
that  all  AMBIT/G  nodes  were  created  at  initialization,  and  their  existence 
is  permanent  for  the  duration  of  AMBIT/G  execution.  All  the  loader  does  to 
AMBIT/G  data,  therefore,  is  connect  various  nodes  by  links  which  it  sets. 
Usually,  any  link  set  by  the  loader  was  undefined  (pointing  at  'undef  undef'), 
but  no  check  is  made  for  this.  The  loader  is  also  capable  of  defining  links , 
which  it  does  by  making  write  calls  on  the  built-ins  'read_function'  and 
'write  function'. 
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The  loader  makes  extensive  use  of  the  built-in  'locate' ,  often  to  find 

on  unnamed  node  of  a  given  type.  In  such  a  case,  if  that  node  is  not  linked  to 
be  accessible  from  an  accessible  node  it  is  lost  in  the  data  base  forever. 

Although  the  loader  is  used  to  load  data,  data  can  include  an  AMBIT/G 
rule  as  a  gilorified  node.  The  loading  of  programs  makes  extensive  use  of 
this  feature.  The  loading  of  a  rule  causes  the  representation  of  that  rule  in 
AMBIT/G  data  according  to  the  specifications  given  in  the  chapter  on  represen¬ 
tation  of  programs.  In  making  up  the  representation  of  a  rule,  the  loader 
links  together  a  'rule'  node  with  unnamed  'linkrep's,  'diamond's,  and  'noderep's 
along  with  the  various  named  nodes  used  in  rule  representations.  Each  named 
node  explicitly  mentioned  in  a  rule  is  located  by  the  loader  and  ends  up  as  the 
destination  of  a  'rep'  link  of  a  'noderep'  in  that  rule's  representation. 

Since  the  loader  can  be  called  by  a  user  program  as  well  as  by  the 
initial  'rule  start'  it  does  not  output  anything  to  the  terminal  unless  an  error 

condition  is  detected.  An  error  causes  an  indicative  message  to  ba  typed 
and  execution  to  be  terminated. 

ERROR  MESSAGES  OF  THE  AMBIT/G  LOADER 

The  following  is  a  list  of  the  various  error  messages  which  may  be 
typed  out  as  a  result  of  the  loader's  detecting  an  error  condition.  The  use 
of  three  periods  is  to  indicate  a  character  string  will  be  typed  according  to 
the  state  of  the  data  or  the  loader  input.  The  following  line  is  typed  along 
with  every  loader  error  message  except  the  last: 

AMBIT/G  Error:  detected  by  the  loader  at  statement  r»  on  page  £ 
where  £  i<5  «n  Integer,  and  £  Is  a  page-title  (string  of  characters). 


1. 


2. 


System  implementation  error  in  the  loader  probably  due  to  improper 
data;  a  frame  does  not  match  because  "  ,,,  "  is  not  the  same  as 

ft  II 

•  •  •  • 


System  implementation  error  in  the  loader  probably  due  to  improper 
data;  a  frame  does  not  match  because  a  link  with  origin  "  "  and 

name  "  .,,  "  points  to  destination  "  ...  "  instead  of  "  ...  "  , 
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3. 


System  implementation  error  in  the  loader  probably  due  to  improper 
data;  a  frame  does  not  match  because  "  ...  "is  not  of  type  "  ..."  . 

4.  System  implementation  error  in  the  loader  due  to  an  oversight  by  the 
implementor;  a  rule  took  an  unexpected  fail  exit. 

5.  The  first  statement  read  by  the  loader  does  not  begin  with  a  "  -  "  . 

6.  "  ..."  is  an  unknown  statement. 

7.  A  type-name  is  missing  on  a  node  on  a  loader  page. 

8.  A  page-name  is  missing  for  a  "-rule-"  or  "-ruleref-"  on  a  loader  page. 

9.  There  is  an  unknown  line  in  a  rule  contents  on  a  loader  page. 

10.  There  is  an  incomplete  statement  on  a  loader  page. 

11.  "  ..."  is  an  extra  special  character  on  a  loader  page. 

12.  "  is  an  undeclared  page-name  on  a  loader  page. 

13.  System  Implementation  error  in  the  interpreter  or  loader  probably  due 

to  Improper  data;  a  frame  does  not  match  because  a  link  with  origin 

"  . . .  "  and  name  "  ...  "  points  to  destination  "  ...  ",  which  is  not 
of  type  "  ...  " . 


51 


AMBIT/G  LOADER  SYNTAX 


In  designing  the  syntax  for  the  loader,  we  established  some  require¬ 
ments  based  on  the  readability  of  a  loader  page.  A  loader  page  is  intended 
to  be  a  sequence  of  text  lines  representing  one  physical  page  or  sheet  of 
AMBIT/G  diagrams .  Such  a  page  may  be  arbitrarily  large  and  contain  dia¬ 
grams  representing  any  mixture  of  rules,  data,  and  link  definitions. 

We  shall  provide  a  grammar  for  the  syntax  in  a  BNF-like  specification 
language.  However,  we  will  first  give  informally  the  lexical  conventions 
which  apply  to  loader  input  to  produce  the  syntax  of  a  statement. 

The  readability  requirement  affects  the  interpretation  of  spaces,  tabs, 
and  new-lines  (carriage  returns)  .  Since  we  can't  determine  by  reading,  spaces 
and  tabs  are  not  distinguished;  furthermore,  to  avcid  a  requirement  for  count¬ 
ing,  any  amount  of  space  on  a  typed  line  is  treated  as  a  single  space.  Since 
a  reader  cannot  see  trailing  space  it  is  ignored.  Similarly,  since  the  exact 
position  of  a  left  margin  can  be  uncertain,  leading  space  is  ignored.  Since 
line  spacing  is  difficult  to  see,  any  blank  line  (even  if  it  contains  a  space) 
is  ignored.  A  loader  page  should  otherwise  include  only  visible  printing  char¬ 
acters  of  the  ASCII  character  set. 

Another  requirement  of  the  syntax  is  its  ability  to  represent  AMBIT/G 
node  names  which  may  consist  of  any  sequence  of  printing  characters.  Thus 
when  a  special  meaning  is  given  to  a  character,  such  as  semicolon,  there 
must  also  be  a  method  of  inputting  a  semicolon  as  a  normal  text  character. 

This  has  been  accomplished  by  giving  the  dollar  sign  a  special  meaning  as 
a  protection  character.  Namely,  when  a  statement  includes  a  dollar  sign 
which  is  itself  unprotected,  that  dollar  sign  protects  the  very  next  character 
fiom  having  special  meaning.  The  following  list  presents  all  printable  char¬ 
acters  which  have  special  meaning  in  the  loader  syntax: 

$;/!?():*, 

Any  of  these  special  characters  must  be  protected  in  order  to  be  understood 
as  a  normal  text  character.  Any  other  character  may  be  protected  by  a  dollar 
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sign,  but  protection  has  no  effect;  this  means  a  user  can't  go  wrong  if  he 
protects  a  character  when  he  is  not  sure  whether  it  has  a  special  meaning. 

When  a  dollar  sign  ends  a  text  line,  it  can  be  considered  as  a  pro¬ 
tection  of  the  new -line  (or  carriage  return)  character.  Normally  the  end  of 
a  line  denotes  the  end  of  a  statement.  If  a  line  ends  with  an  unprotected 
dollar  sign,  however,  that  special  meaning  is  nullified,  and  instead  the 
statement  is  interpreted  as  continuing  on  the  next  line.  Any  number  of 
continuations  may  be  given.  Note  that  since  leading  and  trailing  spaces  are 
ignored,  it  may  be  necessary  to  protect  a  space  at  the  beginning  of  a  line 
which  is  part  of  a  continued  statement. 

We  have  described  how  an  individual  statement  may  spread  over 
several  lines.  The  complementary  ability  to  include  several  statements  on 
one  line  is  provided  by  using  an  unprotected  semicolon  as  a  statement  term¬ 
inator. 


Input  to  the  loader  may  include  comment  statements  anywhere.  A 
comment  statement  begins  with  an  asterisk  and  ends  either  at  the  end  of  a 
line  (which  is  not  continued)  or  at  an  unprotected  semicolon.  Within  a 
comment  it  is  not  necessary  to  protect  any  other  special  characters. 

The  loader  performs  its  inputting  by  calling  a  function  named 
'get_.statement' .  That  function  takes  into  account  all  the  lexical  conventions  Just 
described.  It  reads  the  input  stream  character  by  character  and  produces  an 
output  stream  of  one  loader  statement  each  time  it  is  called.  Its  output  does 
not  include  null  statements  nor  comment  statements.  Protective  dollar  signs 
are  removed,  and  unprotected  special  characters  are  converted  into  objects 
which  are  not  ASCII  characters,  but  serve  as  an  extension  to  the  character 
set.  We  will,  however,  denote  these  special  objects  in  the  loader  syntax 
by  the  corresponding  ASCII  character.  Each  space  produced  by  'get^statement' 
is  also  one  of  these  special  objects;  it  will  be  denoted  by  'SP' . 

Spacing  and  the  use  of  separate  lines  are  used  inthe  loader  syntax 
grammar  for  readability  and  do  not  affect  the  meaning.  Ends  of  statements 
are  denoted  by  a  semicolon,  but  recall  a  semicolon  is  required  to  end  a 
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statement  only  when  more  toxt  follows  on  the  same  line.  Meta-variables 
(non-terminals)  are  underlined  strings  consisting  of  alphabetic  characters 
and  hyphens. 

A  vertical  bur  in  the  grammar  represents  disjunction.  A  matching  pair 
of  vertical  brackets  indicates  they  encloso  an  optional  construct;  namely,  the 
syntax  allows  for  either  zero  or  one  occurrence.  A  matching  pair  of  vertical 
curly  braces  Indicator,  they  enclose  a  construct  which  may  be  repeated  any 
number  of  timos,  Including  zero. 

Tho  grammar  Is  designed  not  to  bo  minimal  nor  reflect  Its  Implemen¬ 
tation;  it  Is  supposed  to  bo  oasily  understood  and  to  correspond  to  what  It 
roprosonts.  Tho  grammar  provides  tho  definition  of  a  'loader-input*  which 
is  the  string  of  characters  which  tho  loador  processes  as  a  result  of  one 
invocation  unless  an  orror  condition  Is  detected.  One  'loader-input'  consists 
of  any  number  of  'loador-paqo's  finally  followed  by  a  ' start- statement* .  Each 
'loader-page'  begins  with  a  header  which  should  contain  a  'page-title'  since 
that  title  Is  typed  when  an  error  is  detected  by  the  loader  on  tint  page.  Then 
any  number  of  'data-node' s  are  specified;  each  one  may  either  refer  to  a 
'node'  In  the  data  of  a  given  type  (possibly  unnamed)  or  a  'rule'  or  a  refer¬ 
ence  of  a  rule  ('ruleref')  .  Next  (and  last)  on  a  pago  are  representations 
of  links  ('data -link's)  to  be  initialized  in  the  data.  This  includes  'success* 
and  'fail'  links  connecting  rules  on  the  page. 

A  rule  is  an  elaborate  generalization  of  a  node  with  a  substructure 
resembling  the  super-structure  of  a  'loader-pace' .  Namely,  each  'rule'  begins 
with  a  header  and  then  contains  specifications  of  'rule-node's  followed  by 
'rule-link's  .  Unlike  a  'page',  the  end  of  a  rule  is  clearly  indicated  by  an 
'-endrule-'  statement. 

To  permit  the  mentioning  of  'data-node' s  in  'data-llnk's  each  node 
specification  Includes  a  'page-name'  which  is  an  identifier  whose  scope  is 
the  current  page.  (Wc  now  realize  this  kind  of  identifier  would  have  been 
better  named  'Instance -name but  'page-name'  is  used  throughout  programs 
and  documentation  so  it  has  been  kept;  we  apologize  to  the  reader.)  'rule' 
and  'ruleref  specifications  also  include  a  'page-name'  for  the  same  reason. 

Tho  user  should  think  of  the  page-name  as  corresponding  to  a  box  in  the 
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AMBIT/G  diagram:  either  a  box  representing  a  node,  a  larger  one  representing 
a  rule  (with  contents},  or  a  rounded  rectangle  representing  a  rule  reference. 

We  have  found  It  convenient  to  choose  page-names  In  tho  spirit  of  encoding 
AMBITA  diagrams:  the  page  may  be  thought  of  os  having  a  grid  of  rows  and 
columns.  Rows  are  named  'a1,  'b',  'c',  etc.,  and  columns  are  namod  with 
tho  lntegors  beginning  at  T.  A  page-name  is  thon  choson  according  to  tho 
coordinate  position  of  the  box  it  represents.  Foroxomplo,  '1)3'  Is  tho  third 
column  of  the  second  row.  The  doctsion  of  whothcr  to  adopt  this  suggestion 
is  at  the  user's  discretion.  Ho  may  profor  to  omploy  words  of  mnomonlc  valuo. 

Within  a  rule,  'rule-paqe-name's  serve  tho  same  purpose  as 
'pngo-namo's,  but  their  scope  is  only  the  current  rule.  Thus  if  u  page  contains 
more  than  one  rulo,  eoch  rule  may  include  the  very  some  rule-pego-namos , 
and  furthermore,  they  may  be  tho  sumo  os  page- names  employed  on  the 
lotider-pugc  at  large. 

The  syntax  allows  for  specification  of  'data-llnk's  and  'rule-link's 
in  two  different  forms:  using  a  textual  'link-label*  or  by  referencing  a  node 
by  its  page-name.  The  lattor  form  corresponds  to  the  more  primitive  view 
of  a  link  with  a  spur  to  a  node.  The  loader  processes  a  'link-label*  xvz  by 
treating  it  as  a  spur  to  tho  node  'link  xvz'. 

These  explanatory  notes  huve  been  intended  to  givo  the  reader  a 
"push"  into  the  grammar;  we  do  not  consider  it  necessary  to  discuss  all  of 
its  details,  following  the  grammar  is  a  small  sample  of  the  encodement  of 
a  complete  thrt  r-page  AMBIT/G  program. 
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Cirnminar  of  Loader  Syntax 


1. 

loader- input 

— ) 

{londor-nago)  start-statomont 

2. 

loadcr-pano 

— ) 

oano-hoador 

(data -nodo) 

f  -rinks-  :  (  data-link  )  1 

3. 

Daao-hcader 

— > 

-oaao-  f  r  SP 1  pngo-title  )  ; 

4. 

data-nodo 

— > 

nodo  1  rulo  1  rulorof 

5. 

nodo 

— > 

tvood-nodo  1  namod-node 

6. 

tvpod-nodo 

Ddao-namo  bod  tvne  : 

7. 

namod-nodo 

— > 

oaoe-namo  sen  typo  sop  subname  : 

8. 

nilo 

rulo-hoader 

f  rule-nodo  ) 

f  —  :  (rulo-link)  1 

-endrulo-  ; 

9. 

rule-hoador 

— > 

-rulo-  fSPl  oaae-namo  f  SP  label  ]  : 

10. 

rule-nodo  _ 

^  Unnamed 

-rule-node  1  tested-tvnod-rule-nodc  1 

tvoed-rulo-node  1  named-rule-node 

11. 

unnaniQdr  nilo -node 

— > 

rule-paao-name  ; 

12. 

tested -typed -rule -nodo  — > 

tvoed-rulo-node  ?  : 

13. 

tvDed-rulo-node 

— > 

rule-paao-name  sod  tvoe  : 

14. 

namod-rulo-node 

— > 

rulo -paao -name  sod  tvoe  sod  subname 

IS. 

rule-link  - > 

rule-link- 

ora  sen  rule -link-name  sod  rule-llnk-dost : 

16. 

rule-link-orq 

— ) 

rule  -link-org  -de  st 

17. 

rule -link-name 

— ) 

frame -rule-link  1  test-rule-link  | 

modify-  rule  -link 

18. 

rule -link- do  st 

— > 

rulo-link-org-dest 
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19. 

20. 
21. 
22. 

23. 

24. 

25. 

26. 

27. 

28. 

29. 

30. 

31. 

32. 

33. 

34. 

35. 

36. 

37. 

38. 

39. 

40. 

41. 

42. 

43. 

44. 


link-label 


\DL  — >  :  JliiL  -tKnjo-Qatne 

iest  —  >  rulo-pago-namo  | 

(fSP)  f  rule -page -name  (lUt-sop  i 


>-namo  (lUt-sop  mle-paqe-name)  flf]  ]  ) 
-rulerof- [§P )  page-name  f  SP  label  1  ; 


ruleref  — »  -nilerof-  [  §P  J  page-name  i  SP  label  I  ; 

data-llnk  — >  dofllnks  |  link 

defllnks  — > 

-deflinke-f  §P  1  type  f  .§£  )  (  f  £P  ]  llnk-namo  (llst-sep  link-name)  f§£) )  ; 
link  — >  llnk-oro  sep  link-name  sop  llnk-dost  : 

Unk-ora  — >  page-name 

link-name  — »  labelled-link  |  spurred-Unk 


Ink-name 


gpunrcd-lipk 


pma-nama 


label 

UnKzlsba) 

type 

subname 


llst-sei 


page -title 
limited-identifier 


link-label 


:  page-name 


-start- f  fSPl  label)  ; 


subnama 

subname 

Identifier 

Identifier 

SP  I  .  I  / 

SP  I  ,  fSPl 

(any  string  without  statement  terminator) 
(  any  identifier  which  does  not  begin 
with  a  minus  sign) 
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45.  Identifier 
(END) 


— t  (any  string  of  printing  characters) 


A  SAMPLE  ENCOPEMENT 


Bolow  is  an  actual  listing  of  tho  filo  'revorsol.ambltg'  representing 
tho  snail  yot  comploto  threo-page  AMBITUS  program  which  follows. 


reverse!. ambl tg  12/30/70  2035.3  est  Wed 


-page-  rl-1 
-1  Inks- 

-def 1  inks*  p  (d) 
*def I  inks*  end  ( r ) 
-def l Inks-  c  ( r,d) 

-page-  rl-2 
al  p  x 
a5  p  y 
bl  c 
b2  c 
b3  c 
b4  c 

b5  end  c 
cl  char  P 
c2  char  0 
c3  char  T 
c4  char  S 

-1 Inks- 


al 

d 

bl 

a5 

d 

b5 

bl 

r 

b2 

b2 

r 

b3 

b3 

r 

b4 

b4 

r 

b5 

b5 

r 

b5 

bl 

d 

cl 

b2 

d 

c2 

b3 

d 

c3 

b4 

d 

c4 

(Cont’  on  next  page) 
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-page*  rl-3 
-rule-  rl  reverse-l 
al  p  y 
a)  p  x 
bl 

b2  c? 
b3 

al  d  bl 
al  dl  b2 
o3  d  b2 
a3  dl  b3 
b2  rl  bl 
b2  r  b3 
-endrule- 

-ruleref-  r2  stop 

-I Inks- 
rl  success  rl 
rl  fall  r2 

-start-  revorso-1 
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reverse! 


60 


rl-2 
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( 
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A  SAMPLE  ERROR 


The  following  page  Is  terminal  output  of  anAMBIT/G  run  on 
Multlcs  which  causes  a  loader-detected  error  condition  (number  12). 
Following  the  listing  of  the  run  Is  a  listing  of  the  program  which 
caused  the  error.  The  arrows  added  to  the  output  Indicate  lines  typed 
In  by  the  user. 
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Multics  13.1,  load  8. 0/41. 0;  7  users 
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CHAPTER  6 


INITIALIZATION  AND  THE  BUILT-IN  SYSTEM 


To  make  an  AMBIT/G  run  using  the  Multics  AMBIT/G  System  a  user 
must  prepare  two  source  files.  One  file  is  for  normal  input  to  the  system; 
it  will  be  read  by  the  AMBIT/G  loader  and  by  the  user's  program  calling 
upon  the  built-in  function  which  reads  from  the  input  file.  The  other  file 
is  read  only  by  the  AMBIT/G  initializer  early  in  the  run  and  it  plays  no 
further  role  after  initialization  is  complete;  this  file  is  called  the  hint  file 
since  its  role  in  the  system  is  considered  to  be  outside  of  the  definition  of 
the  AMBIT/G  language.  We  call  the  contents  of  the  hint  file  "hint  informa¬ 
tion"  or  Just  "hints" . 

This  chapter  describes  the  syntax  and  semantics  of  the  hint  file, 
and  a  user's  view  of  the  initialization  process  is  given.  It  also  contains 
a  complete  description  of  the  initial  state  of  the  AMBIT/G  System  as  seen  by 
a  user's  program.  This  includes  all  built-in  nodes,  defined  links,  initial 
links,  and  built-in  rules.  All  built-in  functions  other  than  the  loader  are 
described  and  their  built-in  definitions  are  given. 

HINTS 


A  hint  file  has  three  parts.  It  begins  with  any  number  (including 
zero)  of  settings  of  hint  variables  which  control  the  AMBIT/G  System  ini¬ 
tialization.  Those  variables  have  default  settings  for  every  run,  but  the 
hint  file  can  override  the  default  settings.  However,  these  overriding 
settings  must  be  consistent  with  initialization  of  the  built-in  data  and 
functions.  The  following  table  outlines  this  informations 


Variable 


Default  Value  Meaning,  Restrictions 


smallest_integer  -999 

largest_lnteger  999 


'integer's  are  built-in  nodes,  and 
these  variables  establish  the  range  of 
created  'integer'  nodes. 
'smallest_integer'  must  not  be  greater 
than  'largest_integer'.  Note  that 
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function_arguments  10 


defns  size  5000 


names  size  1000 


name_length  25 


'largest_integer'  should  be  greater 
than  the  number  of  statements  Included 
on  a  loader  page ,  since  the  loader 
tallies  a  count  of  statements  using 
'integer's. 

This  variable  indicates  the  maximum 
number  of  tail  arguments  which  can 
be  included  in  a  function  call.  It 
also  is  an  upper  limit  on  the  number  of 
of  arguments  for  which  a  function  may 
be  defined.  It  must  be  at  least  2. 

This  variable  is  used  to  limit  the  size 
of  the  segment  used  to  store  function 
definitions.  A  larger  number  does  not 
raise  costs,  but  it  must  be  less  than 
65000.  Its  moderate  setting  may  be 
useful  for  catching  errors  in  a  program 
which  gets  into  a  loop  defining  too 
many  functions.  It  must  be  at  least 
347  plus  twice  the  value  of 
'function_arguments' . 

This  variable  indicates  the  maximum 
number  of  names  which  may  be  accomo¬ 
dated  in  the  symbol  table  (names_seg- 
ment).  It  must  be  at  least  200. 

This  variable  indicates  the  maximum 
number  of  characters  which  may  be  used 
in  a  name.  It  must  be  at  least  14. 


The  second  portion  of  the  hint  file  specifies  the  names  and  counts  of 
all  types  of  terminal  nodes  (having  no  links)*  which  are  to  be  created  in 
additon  to  the  built-in  nodes.  The  given  count  must  be  greater  than  zero.  The 
following  list  indicates  the  built-in  terminal  type  names  and  the  number  of 
nodes  which  are  always  created. 


Terminal  type 


Count 


flag 

link 

builtin 

undef 

boolean 

char 

special 


13 

36  (built-in)  +  100  (for  user) 
15 
1 
2 

128 

9 
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integer 

type 


large st_integer  -  smallest_integer  +  1 
(19  plus  additional  ones  defined  by  the 
user  in  the  hints) 


The  hint  file  may  include  one  mention  of  any  of  the  built-in  terminal 
types  other  than  'integer1  and  'type' .  The  given  associated  count  will  be 
added  to  the  built-in  count.  For  example,  if  the  user  wishes  to  extend  the 
class  of  nodes  of  type  'char'  by  eight  more  nodes,  he  would  include  in  the 
second  portion  of  the  hint  file  the  terminal  type  name  "char"  and  the  integer 
'8'.  Thus  136  nodes  of  type  'char'  would  be  created. 

The  third  portion  of  the  hint  file  specifies  the  names,  counts,  and 
maximum  number  of  links  of  all  types  of  non-terminal  nodes  which  are  to 
be  created  other  than  the  built-in  nodes.  The  given  count  must  be  greater 
than  zero. 

Since  various  non-terminal  nodes  are  used  to  represent  a  user's  pro¬ 
gram  and  the  need  for  certain  other  nodes  varies  according  to  the  ways  in 
which  a  program  uses  functions,  the  overriding  mechanism  is  more  complex 
than  for  terminals.  If  the  hint  file  does  not  mention  a  built-in  non-terminal 
type  then  the  number  of  nodes  of  that  type  created  is  the  sum  of  the  built-in 
count  plus  the  default  additional  count.  However,  if  a  built-in  non-terminal 
is  included  in  the  third  portion  of  the  hint  file  the  given  count  is  added  to 
the  built-in  count,  thus  overriding  the  default  additional  count.  Furthermore, 
the  given  number  of  links  is  added  to  the  built-in  number  of  links.  The  given 
number  of  links  for  a  built-in  non-terminal  may  therefore  be  any  positive 
integer  including  zero.  The  given  number  of  links  for  user-defined  non¬ 
terminal  types  must  be  greater  than  zero.  The  following  list  presents  the  relevant 
information  for  built-in  non-terminals. 


Non -Terminal  Type 

Count 

Default  Additional 

Number  of  Links 

.rule 

6 

50 

12 

linkrep 

11 

500 

6 

Pipe 

4 

100 

2 

cell  4  +  function^arguments 

functicn_arguments 

2 

charconn 

103 

1900 

2 
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ptr 

2 

0 

1 

noderep 

13 

500 

3 

circle 

42 

0 

1 

diamond 

15 

10  o0 

2 

pname 

2 

100 

3 

A  type  name  must  not  appear  more  than  once  in  the  hint  file.  Also, 
a  built-in  terminal  cannot  be  promoted  to  a  non-terminal. 


Hint  Syntax 

The  syntax  of  the  hint  file  corresponds  to  the  requirements  for 
simple  use  of  PL/T input  functions.  Below  is  given  a  grammar  for  the  syntax 
in  a  BNF-like  specification  language.  Spacing  is  used  for  readability  and 
does  not  affect  the  meaning.  Meta- variables  (non-terminals)  are  underlined 
strings  consisting  of  alphabetic  characters  and  hyphens.  A  vertical  bar  in 
the  grammar  represents  disjunction.  A  matching  pair  of  vertical  brackets 
indicates  they  enclose  an  optional  construct?  namely,  the  syntax  allows  for 
either  zero  or  one  occurrence  .  A  matching  pair  of  curly  braces  indicates 
they  enclose  a  construct  which  may  be  repeated  any  number  of  times,  in¬ 
cluding  zero. 
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Grammar: 


1 .  hints 

2.  set-hint-variable 

3.  terminal-spec 

4.  non-terminal-spec 

5.  hint-variable 

6.  integer 

7.  digit 

8.  type 

0.  SP 

10.  NL 


— ^  {  set-hint-variable  NL  } 

;  NL 

{  terminal-spec  NL  } 

""  NL 

{  non-terminal-spec  NL  } 

NL 

— ^  hint-variable  =  integer 

— )  "type"  SP  integer 

— ^  "type"  SP  integer  SP  Integer 

— }  smallest_integer  [  large  st_integer  [ 
function_arguments  [  defns_size  | 
names_size  l  name_length 

— ?  [  -  ]  digit  {  digit  } 

— >  0  [  1  l  2  |  3  |  4  [  5  [  6  |  7  [  8  [  9 

— ^  (any  (non-null)  string  of  printing  characters  , 
except  double  quotes  must  be  in  pairs) 

— >  (space  composed  of  any  (non-pull)  mixture 
of  spaces  and  tabs) 

— }  (new -line  (cartage  return)) 
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An  Example 


A  rhort  example  of  a  hint  file  follows  as  an  actual  listing  of  the 
file  'reversel  .hints' .  This  file  is  the  mate  of  the  file  listed  as  an  ex¬ 
ample  in  the  chapter  on  the  loader.  Furthermore,  the  'reversel'  program 
is  discussed  in  detail  as  the  first  example  in  Volume  II  of  this  report. 


reversel. hints  12/30/70  2035.3  est  Wed 


/ 

llll 

"p"  2  1 

"end"  1  1 

"c "  4  2 

llll 
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BUILT-IN  NODES 


As  it  reads  the  three  portions  of  the  hint  file,  the  initializer  creates 
all  nodes  which  can  be  used  in  the  AMBIT/G  run.  It  then  attaches  names  to 
the  named  built-in  nodes.  These  are  named  nodes  of  the  interpreter  and 
loader  and  other  nodes  which  are  part  of  the  AMBIT/G  System. 

An  AMBIT/G  programmer  should  avoid  using  any  built-in  nodes  in 
his  programs  other  than  for  their  intended  purpose.  The  programmer  is  ad¬ 
vised  not  to  use  type  names  which  are  built-in  for  anything  but  their  intended 
use.  For  example,  a  programmer  should  not  employ  nodes  of  type  'circle'  in 
a  program  to  represent  an  arbitrary  variable. 

The  following  is  a  comprehensive  list  by  type  of  all  named  built-in 
nodes.  fTheir  order  corresponds  to  ordering  in  the  implementation  of  the 
'nodes  segment'.) 


flag 

clear 

compiled 

frame 

test 

modify 

ok 

dummy 

no 

any 

def 

general 

undef 

fixed 

link 

heads 

spur 

tails 

state 

success 

contents 

frame 

test 

modify 

fail 

savel 

saveret 

mode 

org 

name 

dest 

next 

nextl 

value 

sets 

variability 

rep 

link' 

read_function 

write_f  unction 

locate 

type 

char 

load 

add 

subtract 

node 

multiply 

divide 

sign 

pname 

builtin 

link 

link' 

read_function 

write_function 

locate 

name 

type 

char 

load 

add 

subtract 

multiply 

divide 

sign 

error 
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undef 


undef 

boolean 

true  false 

char 


NUL 

SOH 

STX 

ETX 

EOT 

ENQ‘ 

ACK 

BEL 

BS 

HT 

LF 

VT 

FF 

CR 

SO 

SI 

DLE 

DC1 

DC  2 

DC  3 

DC  4 

NAK 

SYN 

ETB 

CAN 

EM 

SUB 

ESC 

FS 

GS 

RS 

US 

SP 

; 

If 

# 

$ 

% 

& 

l 

( 

) 

* 

+ 

» 

- 

o 

/ 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

• 

• 

i 

< 

= 

> 

• 

@ 

A 

B 

C 

D 

E 

F 

G 

H 

I 

J 

K 

L 

M 

N 

O 

P 

Q 

R 

S 

T 

U 

V 

W 

X 

Y 

Z 

f 

\ 

] 

A 

_ 

a 

b 

c 

d 

e 

f 

g 

h 

i 

J 

k 

1 

m 

n 

o 

P 

q 

r 

s 

t 

u 

V 

w 

X 

DEL 

y 

z 

{ 

1 

} 

special 

SP 

/ 

# 

! 

? 

( 

) 

* 


integer 

(all  integers  between  smallest_integer  and  large  st_integer;  e.g.  ... 

-5  -4  -3  -2-10  1 

2345...) 
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type 

(any  user- 

•defined  types  plus:) 

flag 

link 

builtln 

undef 

boolean 

char 

special 

integer 

type 

rute 

linkrep 

pipe 

cell 

charconn 

ptr 

noderep 

circle 

diamond 

pname 

rule 

go 

stop 

error 

help 

ret 

start 

linkrep 

fl 

tl 

ml 

begin 

end 

free 

end 

h 

cell 

free 

end 

h 

charconn 

free 

end 

J&L 

ret 

next_rule 

noderep 

(none) 

circle 

a 

b 

c 

d 

dl 

d2 

end 

f 

free 

dest 

1 

11 

mode 

n 

r 

ret 

rule 

fl 

ml 

tl 

proceed 

char 

next_pname  pname_list 

pname 

node 

org 

name 

prev_char 

findl 

find  2 

char_a 

char_b 

first_ch 

last_ch 

end_line 

save_pname  special 

find_pname  paren 

page 

line 

73 


diamond 


end  matched  unmatched  h 

pname 

end 


BUILT-IN  LINKS 


The  following  is  a  complete  list  by  node  type  of  all  defined  links 
which  are  built-in.  (Their  order  corresponds  to  ordering  in  the  implementation 
of  the  'nodes_segment'  and  'defns_segment' .)  All  built-in  link  names  are 
nodes  of  type  'link' ,  and  therefore  the  given  names  are  their  subnames. 


rule 


state 

success 

fail 

saveret 

savel 

heads 

spur 

tails 

contents 

frame 

test 

modify 

linkrep 

org 

name 

dest 

next 

nextl 

mode 

PiBg. 

next  value 

cell 

next  value 

charconn 

next  value 

£tr_ 

value 
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noderep 

rep 


variability 


sets 


circle 

value 

diamond 

next  value 


pname 

next  pname  node 


BUILT-IN  FUNCTION  DEFINITIONS 

Each  of  the  built-in  functions  is  initially  defined  as  if  write  calls 
has  been  made  on  'read_function'  and  'wrlte_functlon' .  These  built-in  defl 
nitions  are  initialized  (in  the  'defns_segment')  before  built-in  links  are 
defined.  The  following  table  summarizes  these  definitions.  All  built-in 
link  names  are  nodes  of  type  'link'  and  therefore  the  given  names  are  their 
subnames.  (Their  order  corresponds  to  ordering  in  the  Implementation  of 
the  'defns_segment'.) 


Read/  Write 

Link-  Name 

Definition 

Tail  Types 

read 

load 

'bulltln  load1 

(none) 

read 

type 

'builtin  type' 

(any) 

read 

sign 

'builtin  sign' 

integer 

read 

char 

.'builtin  char' 

(any) 

write 

char 

'builtin  char' 

(any) 

read 

add 

'builtin  add' 

integer,  integer 

read 

subtract 

'builtin  subtract' 

integer, int-  jer 

read 

multiply 

'builtin  multiply' 

integer, integer 

read 

divide 

'builtin  divide' 

integer,  integer 

read 

locate 

'builtin  locate' 

type ,  charconn 

read 

name 

'builtin  name' 

(any),charconn 
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r<  .  i 

read  function 

'builtin  read_f unction' 

cell,  (any) 

read 

c 

o 

y 

I 

4— 

u 

2 

'builtin  writo_function' 

cell,  (any) 

road 

link' 

'builtin  link" 

(any),  (any) 

write 

rcad_fuuction 

•builtin  read_function' 

flag,  (any) 

write 

writo_fu  notion 

'builtin  wrlte_function' 

flag,  (any) 

write 

rcad_function 

'builtin  read_function* 

cell,  (any) 

write 

writc?_f  unction 

'builtin  writo_f  unction* 

cell,  (any) 

write 

link' 

•builtin  link" 

(any),  (any) 

Although  nil  of  tho  ubovo  definitions  are  built-in,  it  is  only  necessary 
that  the  fourth  last  one  bo  built-in.  Tho  existence  of  that  one  definition  can 
serve  as  a  bootstrap  to  define  all  of  tho  others* 

BUILT-IN  RULES 

The  initial  AMBIT/G  data  graph  includes  six  built-in  rules.  Two  of 
these  exist  only  as  'rule'  nodes  since  the  interpreter  nevor  attempts  to  look 
at  their  contonts:  'rule  stop'  and  'rule  error'.  The  other  four  built-in  rules 
are  initialized  in  the  'clear'  state  to  be  as  follows.  Note  that  tho  first  two 
rules  have  nc  contents . 


start 


BUILT-IN  DATA 

The  Initial  AMBIT/G  data  graph  includes  various  nodes  which  are 
initially  linked  together  in  addition  to  the  representations  of  the  four 
above  rules.  All  other  built-in  nodes  have  their  built-in  links  undefined 
(pointing  to  'undef  undef1).  The  following  diagram  shows  the  initial  data. 
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BUILT-IN  FUNCTIONS 


A  description  of  each  of  the  built-in  functions  (except  the  loader) 
of  the  AMBIT/G  System  is  included  here.  Each  description  includes  all 
possible  error  conditions  and  messages.  Although  a  built-in  function  will 
normally  be  invoked  by  a  call  which  depends  upon  its  built-in  definition, 
a  program  may  give  a.  built-in  function  as  the  definition  of  what  is  invoked 
for  any  arbitrary  link  name,  etc..  When  the  AMBIT/G  interpreter  processes 
a  link,  it  first  finds  out  the  definition  of  that  link  name  as  applied  to  the 
tails  of  the  link.  If  that  definition  is  a  built-in  then  the  interpreter  checks 
for  the  number  of  tails  and  heads  of  the  link;  it  reports  an  error  if  there  is  a 
discrepancy.  The  interpreter  then  gathers  the  arguments  of  the  built-in 
function  and  performs  a  direct  call  on  it  as  part  of  its  interpretation. 

To  make  it  possible  for  the  interpreter  to  be  itself  a  legitimate  AMBIT/G 
program,  two  nodes  of  type  'bulltin1  are  involved  with  the  reading  and  writing 
of  links.  The  node  'bulltin  link1  should  be  given  as  the  head  argument  of  a 
write  call  on  ' re ad_f unction'  (or  'write^f unction')  to  define  for  reading  (or 
writing)  a  particular  link  name  as  a  true  link  on  a  particular  type  of  node. 

The  node  'bulltin  link"  is  given  as  the  head  argument  of  such  a  call  when 
defining  a  link  to  invoke  the  primitive  link  reading  (or  writing)  function .  This 
difference  will  be  clarified  for  the  reader  by  his  observing  the  listing  of  the 
AMBIT/G  interpreter  where  it  processes  these  built-in  functions.  There  is 
only  one  built-in  function  which  is  the  primitive  link  reading  function  (and 
one  for  writing),  and  it  will  be  described  below. 

type  (read) 


This  function  is  called  with  one  tail  argument  and  one  head  result. 
The  result  of  this  function  is  the  node  of  type  'type'  which  corresponds  to 
the  type  of  the  argument.  Since  every  node  has  a  type  there  are  no  error 
conditions  for  this  function. 

link'  (read) 


This  function  is  called  with  two  tail  arguments  (aroi  and  aro  2 ) 
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and  one  head  result.  The  type  of  anil  is  first  determined;  if  aro  2  is  not 
defined  as  a  true  link  on  nodes  of  that  type,  error  condition  'rll'  is  sig¬ 
nalled.  Otherwise,  the  link  with  origin  arol  and  name  arg 2  is  read,  and 
its  destination  is  returned  as  this  function's  result.  If  the  sought  link  is 
defined  but  has  never  been  written,  the  result  is  the  undefined  node 
'undef  undef . 

The  error  messages  for  this  function  follow. 

rll:  An  attempt  is  being  made  to  read  an  undefined  link 

with  origin  "  ...  "  and  name 


link'  (write) 


This  function  is  called  with  two  tail  arguments  (  arol  and  aro  2  ) 
and  one  head  argument  (  aro  3  )  .  The  type  of  arol  is  first  determined; 
if  aro  2  is  not  defined  as  a  true  link  on  nodes  of  that  type,  error  condition 
•wll'  is  signalled.  Otherwise,  the  link  with  origin  arol  and  name  aro  2 
is  written  to  destination  arg  3.  The  previous  destination  of  that  link  Is 
lost. 


The  error  messages  for  this  function  follow: 

wll:  An  attempt  is  being  made  to  write  an  undefined  link 

with  origin  "  ...  "  and  name  "  ...  "to  destination 


locate  (read) 


This  function  is  called  with  two  tail  arguments  (arol  and  aro  2)  and 
one  head  result.  In  general,  arol  is  a  'type'  node  and  aro  2  is  a  list  of 
printing  characters;  this  function  is  used  to  locate  by  type  ( arol )  and 
subname  (  aro  2  )  a  particular  node .  If  a  null  t  ubname  is  given  a  unique  node 
of  the  given  type  is  located. 

When  initialization  of  an  kMBIT/G  run  is  complete  all  nodes  are 
created  according  to  the  hints.  During  the  execution,  a  call  on  'locate' 
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either  uses  up  a  fresh  node  of  the  given  type  or  it  finds  a  named  node 
which  has  already  been  located  for  the  first  time.  Normally,  the  loader 
locates  all  nodes  during  the  loading  of  data  and  rules,  arg  2  is  supposed 
to  be  a  (possibly  empty)  list  of  connector  nodes  of  type  'charconn'.  These 
are  forwardly- linked  by  'next'  links,  and  'charconn  end'  terminates  the  list. 
Each  other  (if  any)  'charconn'  node  of  the  list  has  a  'value'  link  which  is 
supposed  to  point  to  a  node  of  type  'char'  which  represents  a  printing  char¬ 
acter. 


If  argl  is  not  of  type  'type' ,  error  ccndition  'loc  2'  is  signalled.  If 
an  element  of  the  list  of  arg 2  is  not  of  type  'char' ,  error  condition  'loc  3'  is 
signalled.  If  an  element  of  the  list  of  arg2  does  not  represent  a  printing 
character,  error  condition  'loc  4'  is  signalled.  If  a  connector  of  the  list  of 
arg  2  is  not  of  type  'charconn',  error  condition  'loc  5'  is  signalled.  If  the 
length  of  the  list  of  arg  2  exceeds  the  maximum  length  of  a  name  (according 
to  hint  variable  'nameulength'),  error  condition  'loc  6'  is  signalled. 

After  all  above  checks  are  passed,  if  arg  2  is  a  non-empty  list  it 
is  treated  ap  a  specification  of  the  subname  of  the  node  being  located.  If 
that  node  is  already  known,  it  is  returned  as  the  result.  If  it  is  not  already 
known  (including  the  null  subname  case)  a  fresh  node  of  the  given  type  is 
obtained  to  be  returned  as  result.  If,  however,  all  nodes  of  the  given  type 
have  already  been  located,  error  condition  'loc  7'  is  signalled.  If  a  non-null 
subname  was  given  and  a  fresh  node  is  to  be  obtained,  but  the  system  cannot 
accommodate  another  name  (according  to  hint  variable  'names_size'),  error 
condition  'loc 8'  Is  signalled. 

The  error  messages  for  this  function  follow. 

loci:  The  first  argument  of  a  call  on  the  builtin  "locate”  is 
"  ...  ",  which  is  not  of  type  "type" . 

loc  2  :  The  second  argument  of  a  call  on  the  builtin  "locate"  is 
"  ...  ",  which  is  not  of  type  "charconn"  . 
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loc  3  :  The  second  argument  of  a  call  on  the  builtin  ”  locate" 

is  a  list  beginning  with  "  ...  "  which  includes  a  node 

of  type  "charconn"  whose  "value"  link  points  to  "  ...  " , 
which  is  not  of  type  "char". 

loc  4  :  The  second  argument  of  a  call  on  the  builtin  "locate11 

is  a  list  beginning  with  "  ..."  which  includes  "  . ..  ", 

which  is  an  unprintable  character. 

loc  5  :  The  second  argument  of  a  call  on  the  builtin  "locate1* 

is  a  list  beginning  with  "  ...  "  which  includes  a  node 

of  type  "charconn"  whose  "next"  link  points  to  "...  ", 
which  is  not  of  type  "charconn". 

loc  6 :  The  second  argument  of  a  call  on  the  builtin  "locate" 

is  a  list  of  characters  beginning  with  ”  ...  "  whose 
length  exceeds  capacity. 

loc  7 :  A  call  on  the  builtin  "locate"  is  causing  an  attempt  to 

locate  a  new  node  of  type  ”  ..."  with  second  argument 
"  ...  ",  and  there  is  none. 

loc 8:  A  call  on  the  builtin  "locate"  with  arguments  "  ...  "  and 

"  ...  "is  causing  an  attempt  to  create  a  new  name,  and 
that  would  exceed  capacity, 

name  (read) 


This  function  is  called  with  two  tail  arguments  (arol  and  ara  2)  and 
one  head  result,  arol  is  any  node,  and  this  function  returns  the  subname 
of  the  node  as  a  list  of  its  constituent  characters.  This  result  list  is 
connected  by  'charconn'  nodes  removed  from  a  "free”  list  of  'charconn's 
headed  by  the  'charconn'  node  arc  2.  The  list  given  as  aro  2  and  the  result 
list  are  forward-linked  by  'next*  links,  and  'charconn  end'  terminates  these 
lists.  Each  other  (if  any)  'charconn'  node  of  the  list  has  a  'value'  link  for 
pointing  to  a  'char'  node. 
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If  arg  2  Is  not  a  node  of  type  'charconn',  error  condition  'ml'  is 
signalled.  If  a  connector  node  of  the  list  given  as  arg  2  includes  a  node  to 
be  used  other  than  a  'charconn',  error  condition  'm2*  is  signalled.  If  the 
given  list  of  'charconn' s  does  not  include  enough  of  such  nodes  for  return¬ 
ing  the  subname,  error  condition  'm  3'  is  signalled.  If  argl  has  no  subname, 
the  result  is  'charconn  end'  and  the  given  "free"  list  is  not  affected;  other¬ 
wise,  this  function  has  the  side-effect  of  removing  those  'charconn'  nodes 
which  it  uses  from  that  "free"  list. 

Note  this  built-in  function  is  available  to  a  user  program,  but  it  is 
not  used  anywhere  in  the  system  other  than  one  call  in  the  interpreter  to 
execute  the  function  on  behalf  of  the  user's  program. 

The  error  messages  for  this  function  follow. 

ml:  The  second  argument  of  a  call  on  the  builtin  "name" 

is  "  ..."  ,  which  is  not  of  type  "charconn". 

m  2 :  The  second  argument  of  a  call  on  the  builtin  "name" 

is  a  list  beginning  with  "  ...  "  which  includes  a 

node  of  type  "charconn"  whose  "next"  link  points  to 
"  ...  ",  which  is  not  of  type  "charconn". 

m3:  The  second  argument  of  a  call  on  the  builtin  "name" 

is  a  list  of  nodes  of  type  "charconn"  beginning  with 
"  ...  "  which  is  too  short  to  accommodate  the  subname 

••  it 

OI  •  • •  • 

read  function  (write) 


This  function  is  called  with  two  tail  arguments  (ami  and  arg  2)  and 
one  head  argument  (am  3)  .  It  is  used  to  define  a  reading  function  whose 
definition  is  am  3.  The  link  name  which  will  later  invoke  that  reading 
function  is  am  2.  ami  is  used  as  an  indicator  of  the  number  and  types  of 
tail(s)  which  will  be  required  to  invoke  that  reading  function.  If  there  should 
be  no  restriction  on  the  tails,  ami  should  be  'flag  general '  .  Otherwise, 
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ami  must  be  a  list  where  nodes  of  type  'cell'  are  the  connectors,  'cell's 
are  forwardly-linked  by  'next'  links,  and  'cell  end'  terminates  the  list. 

Each  other  (if  any)  'cell'  node  of  the  list  has  a  'value'  link  to  point  at  the 
list  element.  Each  given  list  element  represents  one  tail  argument  of  the 
reading  function  being  defined.  If  the  element  is  'flag  any'  that  particular 
tail  argument  may  be  any  node.  Otherwise,  a  list  element  must  be  a  node 
of  type  'type'  to  indicate  the  type  of  that  particular  tail  argument  which  is 
required  to  invoke  the  reading  function.  If  arq  2  is  'cell  end'  an  attempt  is 
being  made  to  define  a  reading  function  with  no  tail  arguments . 

If  a  definition  is  made  when  ami  is  not  'flag  general'  whose  domain 
overlaps  with  that  of  a  previous  definition  of  the  same  link  name,  the  newer 
definition  overrides  the  previous  one  for  the  overlapped  domain.  This  is 
discussed  further  in  the  section  describing  'read_functlon  (read)'* 

am  3  must  be  either  a  node  of  type  'builtln'  or  'rule' .  If  am  3  is 
'builtln  link',  this  is  an  attempt  to  define  a  link  for  reading;  therefore,  ami 
must  be  a  list  with  exactly  one  element  which  is  a  'type'  node. 

If  am  3  is  neither  of  type  'builtin'  nor  type  'rule',  error  condition 
'drfl'  is  signalled.  If  arql  Is  neither  'flag  general'  nor  of  type  'cell',  error 
condition  'drf  2'  is  signalled.  If  an  element  of  the  list  given  as  ami  is 
neither  'flag  any'  nor  of  type  'type',  error  condition  'drf  3*  is  signalled.  If 
a  connector  node  of  the  list  given  as  ami  includes  a  node  other  than  a  'cell' , 
error  condition  'drf  4'  is  signalled. 

If  am 3  is  'builtin  link',  then  this  is  an  attempt  to  define  a  link  for 
reading.  If  ami  is  not  a  list  of  one  element,  error  condition  'drf  S'  is  sig¬ 
nalled.  If  another  link  cannot  be  defined  for  the  given  type  because  that 
would  exceed  the  maximum  number  of  links  given  in  the  hints ,  error  condi¬ 
tion  'drf  6'  is  signalled. 

In  defining  any  reading  function,  if  the  system  cannot  accommodate 
that  definition  (according  to  hint  variable  'defns_size') ,  an  error  condition 
'drf  7'  is  signalled.  If  the  number  of  elements  of  the  list  given  as  ami 
exceeds  the  maximum  number  of  arguments  of  a  function  (according  to  h'nt 
variable  'functlon_aiguments'),  then  error  condition  'drf  8'  is  signalled. 
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The  error  messages  for  this  function  follow. 

drfl;  The  head  pointer  of  a  write-call  on  the  builtin 
"read_f  unction:  is  "  ...  ",  which  is  neither  of 
type  “builtin"  nor  of  type  "rule". 

drf2:  The  first  argument  of  a  write-call  on  the  builtin 

"read_function"  is  "  ...  ",  which  is  neither  the 
node  "flag  general"  nor  a  node  of  type  "cell". 

dxf3:  The  first  argument  of  a  write-call  on  the  builtin 

"read_function"  is  a  list  beginning  with  "  ...  ", 
which  includes  a  node  of  type  "cell"  whose  "value" 
link  points  to  "  ...  ",  which  is  neither  the  node 
"flag  any"  nor  a  node  of  type  "type" . 

drf4:  The  first  argument  of  a  write-call  on  the  builtin 

"read_function"  is  a  list  beginning  with  "  ...  * 
which  includes  a  node  of  type  "cell"  whose  "next" 
link  points  to  "  ...  ",  which  is  not  of  type  "cell". 

drf5:  A  write-call  on  the  builtin  "read_function"  is  an 

attempt  to  define  the  link  "  ...  ",  and  the  first 
argument  is  "  ,  which  is  not  a  list  of  one 

lode  of  type  "type". 

drf6:  A  write-call  on  the  builtin  "readJEunction"  is  an 

attempt  to  define  the  link  "  ..."  on  nodes  of  type 
"  ...  ",  and  another  link  cannot  be  defined  for 
this  type. 

drf7:  A  write-call  on  the  builtin  "read_function"  is  causing 

an  attempt  to  make  a  new  definition,  and  that  would 
exceed  capacity. 
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drf8:  The  first  argument  of  a  write-call  on  the  builtin 

"read_function"  is  a  list  beginning  with  "  ...  " 
whose  length  exceeds  the  maximum  number  of 
arguments  allowed  for  a  function  definition. 

write  function  (write) 


This  function  is  called  with  two  tail  arguments  (argl  and  arg  2) 
and  one  head  argument  (  arg3)  .  It  is  used  to  define  a  writing  function 
whose  definition  is  JSXS.3*  The  link  name  which  will  later  invoke  that 
writing  function  is  arg  2  .  argl  is  used  as  an  indicator  of  the  number 
and  types  of  tail(s)  which  will  be  required  to  invoke  that  writing  function. 

If  there  should  be  no  restriction  on  the  tails,  argl  should  be  'flag  general' . 
Otherwise,  argl  must  be  a  list  where  nodes  of  type  'cell'  are  the  con¬ 
nectors.  'cell's  are  forwardly-linked  by  'next'  links,  and  'cell  end'  ter¬ 
minates  the  list.  Each  other  (if  any)  'cell'  node  of  the  list  has  a  'value' 
link  to  point  at  the  list  element.  Each  given  list  element  represents  one 
tail  argument  of  the  writing  function  being  defined.  If  the  element  Is 
'flag  &ny'  that  particular  tall  argument  may  be  any  node.  Otherwise,  a  list 
element  must  be  a  node  of  type  'type'  to  indicate  the  type  of  that  particular 
tall  argument  which  Is  required  to  Invoke  the  writing  function.  If  arg2  Is 
'cell  end'  an  attempt  Is  being  made  to  define  a  writing  function  with  no  tall 
arguments. 

If  a  definition  is  made  when  arg4  is  not  'flag  general'  whose  domain 
overlaps  with  that  of  a  previous  definition  of  the  same  link  name,  the  newer 
definition  overrides  the  previous  one  for  the  overlapped  domain.  This  is 
discussed  further  in  the  section  describing  '  write_function  (read). 

arg  3  must  be  either  a  node  of  type  'builtin'  or  'rule' .  If  arg  3  is 
'builtin  link',  this  is  an  attempt  to  define  a  link  for  writing;  therefore,  argl 
must  be  a  list  with  exactly  one  element  which  is  a  'type'  node. 

If  arg  3  is  neither  of  type  'builtin'  nor  type  'rule' ,  error  condition  'dwfl' 
is  signalled.  If  argils  neither  'flag  general'  nor  of  type  'cell',  error  condi¬ 
tion  'dwf2'  is  signalled.  If  an  element  of  the  list  given  as  argl  is  neither 
'flag  any'  nor  of  type  'type',  error  condition  'dwf3'  is  signalled.  If  a  connect¬ 
or  node  of  the  list  given  as  argl  includes  a  node  other  than  a  'cell' ,  error 


86 


condition  'dwf4'  is  signalled 


If  arg  3  is  'builtin  link',  then  this  is  an  attempt  to  define  a  link  for 
writing.  If  arg*l  is  not  a  list  of  one  element,  error  condition  'dwf5'  is 
signalled.  If  another  link  cannot  be  defined  for  the  given  type  because 
that  would  exceed  the  maximum  number  of  links  given  in  the  hints,  error 
condition  'dwf6'  is  signalled. 

In  defining  any  writing  function,  if  the  system  cannot  accommodate 
that  definition  (according  to  hint  variable  'defns_size'),  error  condition 
'dwf7'  is  signalled.  If  the  number  of  elements  of  the  list  given  as  arg'l 
exceeds  the  maximum  number  of  arguments  of  a  function  (according  to 
hint  variable  'function_arguments') ,  then  error  condition  'dwf8'  is  sig¬ 
nalled. 


The  error  messages  for  this  function  follow. 

dwfl:  The  head  pointer  of  a  write-call  on  the  builtin 

'wiite_function"  is  "  ,  which  is  neither  of 

type  "builtin"  nor  of  type  "rule". 

dwf2:  The  first  argument  of  a  write-call  on  the  builtin 

"write-function"  is  "  ,  which  is  neither  the 

node  "flag  general"  nor  a  node  of  type  "cell". 

dwf3:  The  first  argument  of  a  write-call  on  the  builtin 

"write_function"  is  a  list  beginning  with  "  ...  " 
which  includes  a  node  of  type  "cell"  whose  "value" 
link  points  to  "  ...  ",  which  is  neither  the  node 
"  flag  any"  nor  a  node  of  type  "type" . 

dwf4:  The  first  argument  of  a  write-call  on  the  builtin 

"write_function"  is  a  list  beginning  with  "  ...  " 
which  includes  a  node  of  type  "cell"  whose  "next" 
link  points  to  "  ...  "  ,  which  is  not  of  type  "cell". 
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dwf5:  A  write-call  on  the  builtin  "write_f unction"  is 

an  attempt  to  define  the  link  "  ...  " ,  and  the 
first  argument  is  "  ..."  ,  which  is  not  a  list 
of  one  node  of  type  "type". 

dwf6:  A  write-call  on  the  builtin  "write_f unction"  is 

an  attempt  to  define  the  link  "  ...  "on  nodes 
of  type  "  ...  " ,  and  another  link  cannot  be  de¬ 
fined  for  this  type. 

dwf7:  A  write -call  on  the  builtin  "write_f unction"  is 

causing  an  attempt  to  make  a  new  definition, 
and  that  would  exceed  capacity. 

dwf8:  The  first  argument  of  a  write-call  on  the  builtin 

"write_function'‘  is  a  list  beginning  with  "... 
whose  length  exceeds  the  maximum  number  of 
arguments  allowed  for  a  function  definition! 

read  function  (read) 


This  function  is  called  with  two  tail  arguments  (ami  and  am  2) 
and  one  head  result.  It  is  used  to  determine  the  reading  function  which  is 
defined  to  be  called  for  a  given  link  name ,  am  2  ,  and  with  a  given  sequence 
of  types  of  tail  arguments.  This  sequence  of  types  is  represented  as  ami 
by  a  (possibly  empty)  list  where  nodes  of  type  'cell'  are  the  connectors. 

'cell's  are  forwardly-linked  by  'next'  links,  and  'cell  end'  terminates  the  list. 
Each  other  (if  any)  'cell'  node  of  the  list  has  a  'value'  link  pointing  at  a 
list  element  which  is  a  node  of  type  'type'.  Each  given  list  element  represents 
one  tail  of  the  link  whose  definition  is  sought.  If  there  is  no  definition  for  the 
given  link  name  and  sequence  of  types,  the  result  is  'builtin  error'.  Otherwise, 
this  function's  result  is  either  another  'builtin'  node  or  a  'rule'  node. 

Since  overlapping  domains  might  have  been  given  for  a  particular  link 
name  on  various  write  calls  on  'read__function',  we  include  the  following 
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complicated  description.  For  the  given  number  of  elements  (including  zero) 
of  the  list  presented  as  argl  ,  previous  definitions  are  scanned  for  that 
number  of  elements .  The  scan  is  performed  starting  with  the  most  recent 
definition  and  then  working  backwards  towards  the  oldest  definition.  If  a 
definition  included  'flag  any',  that  argument  position  matches  any  given 
type.  If  a  match  is  found  during  the  scan,  no  further  scanning  is  performed 
and  a  result  is  returned.  If  the  scan  did  not  result  in  any  match,  then  those 
definitions  are  scanned  which  were  made  for  any  general  arguments  as  indi¬ 
cated  by  a  first  tail  argument  of  'flag  general'  on  a  previous  write  call  on 
'read_function' .  As  before,  general  definitions  are  scanned  newest  to  oldest 
There  are  no  built-in  general  definitions .  If  a  match  is  not  found  among  the 
general  definitions,  a  result  of  'builtin  error'  is  returned. 

This  function  is  called  by  the  AMBIT/G  interpreter  for  every  reading 
link  it  processes  to  determine  the  definition  of  that  link.  It  is  not  expected 
to  be  used  within  "normal"  AMBIT/G  programs. 

If  argl  is  not  of  type  'cell',  error  condition  ' grfl'  is  signalled.  If  an 
element  of  the  list  given  as  argl  is  not  of  type  'type' ,  error  condition  'grf2' 
is  signalled.  If  a  connector  node  of  the  list  given  as  argl  includes  a  node 
other  than  a  'cell',  error  condition  'grf3 '  is  signalled.  If  the  number  of 
elements  of  the  list  given  as  argl  exceeds  the  maximum  number  of  arguments 
of  a  function  (according  to  hint  variable  'function_arguments') ,  then  error  con 
dition  'grf4'  is  signalled. 

The  error  messages  for  this  function  follow. 

grfl:  The  first  argument  of  a  read-call  on  the  builtin 

"read_function"  is  "  ...  ",  which  is  not  of  type  "cell". 

grf2:  The  first  argument  of  a  read-call  on  the  builtin 

"read_function"  is  a  list  beginning  with  "  ...  " 
which  includes  a  node  of  type  "cell"  whose  "value" 
link  points  to  "  ...  "  ,  which  is  not  of  type  "type". 

grf3:  The  first  argument  of  a  read-call  on  the  builtin 

"read  function"  is  a  list  beginning  with  "  ...  " 
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which  includes  a  node  of  type  "cell"  whose  "next" 
link  points  to  “  ..."  ,  which  is  not  of  type  "cell" . 

grf4:  The  first  argument  of  a  read-call  '>n  the  builtin 

"read_function"  is  a  list  beginning  with  "  ...  " 

whose  length  exceeds  the  maximum  number  of 
arguments  allowed  for  a  function  definition. 


write  function  (read) 


This  function  is  called  with  two  tail  arguments  (  argl  and  arq  2  )  and 
one  head  result.  It  is  used  to  determine  the  writing  function  which  is  de¬ 
fined  to  be  called  for  a  given  link  name,  arq2.  and  with  a  given  sequence 
of  types  of  tall  arguments.  This  sequence  of  types  is  represented  as  argl 
by  a  (possibly  empty)  list  where  nodes  of  type  'cell*  are  the  connectors. 

'cell's  are  forwardly-linked  by  'next'  links,  and  'cell  end'  terminates  the 
list.  Each  other  (if  any)  'cell'  node  of  the  list  has  a  'value'  link  pointing  at 
a  list  element  which  is  a  node  of  type  'type'.  Each  given  list  element  repre¬ 
sents  one  tail  of  the  link  whose  definition  is  sought.  If  there  is  no  defini¬ 
tion  for  the  given  link  name  and  sequence  of  types,  the  result  is  'builtin  error* • 
Otherwise,  this  function's  result  is  either  another  'builtin'  node  or  a  'rule'  node. 

Since  overlapping  domains  might  have  been  given  for  a  particular 
link  name  on  various  write  calls  on  'writejhinction'.  we  include  the  following 
complicated  description.  For  the  given  number  of  elements  (including  zero) 
of  the  list  presented  as  argl.  previous  definitions  are  scanned  for  that  number 
of  elements.  The  scan  is  performed  starting  with  the  most  recent  definition 
and  the  working  backwards  towards  the  oldest  definition.  If  a  definition 
Included  'flag  any',  that  argument  position  matches  any  given  type.  If  a 
match  is  found  during  the  scan,  no  further  scanning  is  performed  and  a  result 
is  returned.  If  the  scan  did  not  result  in  any  match,  then  those  definitions 
are  scanned  which  were  made  for  any  general  arguments  as  indicated  by  a  first 
tail  argument  of  'flag  general'  on  a  previous  write  call  on  '  write jfunction' .  As 
before,  general  definitions  are  scanned  newest  to  oldest.  There  are  no  built- 
in  general  definitions .  If  a  match  is  not  found  among  the  general  definitions . 
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a  result  of  'builtin  error'  is  returned. 

This  function  is  called  by  the  AMBIT/G  interpreter  for  every  writing 
link  it  processes  to  determine  the  definition  of  that  Jink.  It  Is  not  expected 
to  be  used  within  "normal"  AMBIT/G  programs. 

If  ami  is  not  of  type  'cell' ,  error  condition  'gwfl'  is  signalled.  If 
an  element  of  the  list  given  as  arg  1  is  not  of  type  'type' ,  error  condition 
*gwf2'  is  signalled.  If  a  connector  node  of  the  list  given  as  argl  includes  a 
node  other  than  a  'cell',  error  condition  'gwf3'  is  signalled.  If  the  number 
of  elements  of  the  list  given  as  argl  exceeds  the  maximum  number  of  argu¬ 
ments  of  a  function  (according  to  hint  variable  'function_arguments'),  then 
error  condition  'gwf4'  is  signalled. 

The  error  messages  for  this  function  follow. 

gwfl:  The  first  argument  of  a  read-call  on  the  builtin 

"write -function"  is  "  ...  ",  which  is  not  of  type  "cell". 

gwf2:  The  first  argument  of  a  read-call  on  the  builtin 

"write-function"  is  a  ist  beginning  with  "  ...  " 
which  includes  a  node  of  type  "cell"  whose  "value" 
link  points  to  "...  ",  which  is  not  of  type  "type". 

gwf3:  The  first  argument  of  a  read-call  on  the  builtin 

"write_function"  is  a  list  beginning  with  "  ...  " 
which  includes  a  node  of  type  "cell"  whose  "next" 
link  points  to  "  ...  ”,  which  is  not  of  type  "cell". 

gwf4:  The  first  argument  of  a  read-call  on  the  builtin 

"write_function"  is  a  list  beginning  with  "  ...  " 
whose  length  exceeds  the  maximum  number  of 
arguments  allowed  for  a  function  definition. 
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char  (read) 


This  function  is  called  with  one  tail  argument  (  argl  )  and  one  head 
result.  It  is  used  to  read  (  or  input  )  one  ASCII  character  from  either  the 
input  stream  of  the  user's  typewriter  terminal  or  from  the  normal  input  file 
for  the  AMBIT/G  run  (e .  g . ,  'foo.ambitg') .  The  result  of  this  function  is 
always  a  node  of  type  'char' ,  and  it  is  one  of  the  128  built-in  nodes  of  that 
type.  The  design  of  this  function  may  be  extended  in  the  future  as  other 
input  requirements  present  themselves;  but  presently  only  these  two  devices 
are  available.  If  argl  is  the  node  'char  D'  (for  disk  or  data)  the  character 
is  read  from  the  file.  If,  however,  this  is  an  attempt  to  read  beyond  the 
end  of  the  file,  error  condition  'rcl'  is  signalled.  Any  other  value  of  argl 
causes  a  character  to  be  read  from  the  terminal.  Actually,  the  Multics 
System  "hands  over"  one  line  at  a  time  to  AMBIT/G  ,  so  a  user  must  type  a 
new  line  (carriage  return)  before  any  characters  of  that  line  are  obtainable. 

If  this  function  is  called  when  the  user  has  not  typed  any  input,  it  waits  for 
the  input  indefinitely  with  the  AMBIT/G  System  in  a  dormant  state  with  respect 
to  Multics. 

The  AMBIT/G  implementation  on  Multics  passes  through  whatever 
ASCII  character  it  finds .  The  Multics  convention  is  every  line  ends  in 
only  the  single  character  ASCII  *LF*  (Multics  terminology  is  NL  for  new  line); 
the  AMBIT/G  programmer  should  not  expect  to  find  the  ASCII  'CR*  in  the 
normal  case. 

This  function  is  called  by  the  AMBIT/G  loader  with  an  argument  of 
'char  D'  to  read  the  input  file. 

The  error  messages  for  this  function  follow. 

rd:  A  read-call  on  the  builtin  "char"  with  a  first 

argument  of  "char  D"  is  an  attempt  to  read  beyond 
the  last  character  of  the  input  file. 
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char  (write) 


This  function  Is  called  with  one  tall  argument  (arol)  and  one  head 
argument  tarq  2) .  It  Is  used  to  write  (or  output)  one  ASCII  character  to  the 
output  stream  of  the  user's  typewriter  terminal.  The  design  of  this  function 
may  be  extended  in  the  future  as  other  output  requirements  present  themselves; 
but  presently  only  the  one  device  is  available.  The  character  to  be  written  is 
given  as  ar»2  and  it  must  be  one  of  the  128  built-in  nodes  of  type  'char'; 
otherwise,  error  condition  'wd'  is  signalled. 

This  function  normally  buffers  a  line  of  characters  at  a  time  and 
flushes  that  buffer  only  when  a  'LF'  is  written.  The  AMBIT/G  implementation 
on  Multlcs  passes  through  whatever  ASCII  character  it  finds.  The  Multics 
convention  is  every  line  ends  in  only  the  single  ASCII  'LF'  (Multics  terminology 
is  NL  for  new  line);  the  AMBIT/G  programmer  should  not  normally  write  the 
ASCII  'CR'.  The  line  buffer  can  hold  up  to  130  characters  and  is  flushed  when 
that  buffer  is  full. 

To  permit  interactive  programs  written  in  AMBIT/G  which  have  ques¬ 
tions  and  answers,  this  function  may  be  called  with  arol  as  'char  F'  to_flush 
the  character  buffer,  including  the  current  character  given  as  arg  2  .  Any 
other  value  of  arol  causes  normal  buffering  to  occur. 

The  error  messages  for  this  function  follow. 

wd:  The  head  pointer  of  a  write-call  on  the  builtln 

"char"  is  "...  ",  which  is  not  a  node  of  type 
"char"  which  represents  an  ASCII  character. 
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add  (read) 


This  function  is  called  with  two  tall  arguments  Carol  and  aro  2)  and 
one  head  result.  It  is  used  to  produce  as  result  the  'integer'  node  repre¬ 
senting  the  sum  of  the  integer  represented  by  the  'integer'  node  arol  and 
the  integer  represented  by  the  'integer'  node  aro  2  . 

IS  arol  is  not  of  type  'integer' ,  error  condition  'addl'  is  signalled. 

If  aro  2  is  not  of  type  'integer',  error  condition  'add2'  is  signalled.  If  the 
sum  of  the  two  arguments  is  an  integer  which  is  outside  of  the  range  of 
existing  AMBIT/G  integers  (according  to  hint  variables  'smallest_integer'  and 
' large st_lnteger'  ) ,  error  condition  'add  3'  is  signalled. 

The  error  messages  for  this  function  follow. 

addl:  The  first  argument  of  a  call  on  the  builtln 

"add"  is  "  ...  ",  which  is  not  of  type  "integer". 

add2:  The  second  argument  of  a  call  on  the  builtln 

"add"  is  "...  ",  which  is  not  of  type  "integer". 

add3:  A  call  on  the  builtln  "add"  produced  a  sum  of 

"  ...  ",  which  is  outside  of  the  range  of  integers. 

subtract  (read) 


This  function  is  called  with  two  tail  arguments  (arol  and  aro  2)  and 
one  head  result.  It  is  used  to  produce  as  result  the  'integer  '  node  repre¬ 
senting  the  difference  of  the  integer  represented  by  the  'integer'  node  arol 
minus  the  integer  represented  by  the  'integer'  node  aro  2. 

If  arol  is  not  of  type  'integer,  error  condition  'subl'  is  signalled. 

If  aro  2  is  not  of  type  'integer',  error  condition  'sub2'  is  signalled.  If  the 
difference  of  the  two  arguments  is  an  Integer  which  is  outside  of  the  range 
of  existing  AMBIT/G  integers  (according  to  hint  variables  'smallest_lnteger' 
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and  *  large st_integer'),  error  condition  'sub3'  is  signalled 


The  error  messages  for  this  function  follow. 

subl:  The  first  argument  of  a  call  on  the  builtin 

"subtract"  Is  "  ...  ",  which  is  not  of  type  "integer". 

sub2:  The  second  argument  of  a  call  on  thfouiltin 

"subtract"  is  "  ...  ",  which  is  not  of  type  "integer". 

sub3:  A  call  on  the  builtin  "subtract"  produced  a  difference 

of  "  ...  "  ,  which  is  outside  of  the  range  of  integers  • 

multiply  (read) 


This  function  is  called  with  two  tail  arguments  (arql  and  arg  2)  and 
one  head  result.  It  is  used  to  produce  as  result  the  'integer'  node  representing 
the  product  of  the  integer  represented  by  the  'integer'  node  arol  times  the 
integer  represented  by  the  'integer'  node  arg 2. 

If  arol  is  not  of  type  'integer' ,  error  condition  'mull'  is  signalled. 

If  arg 2  is  not  of  type  'integer',  error  condition  'mul2'  is  signalled.  If  the 
product  of  the  two  argum  ints  is  an  integer  which  is  outside  of  the  range  of 
existing  AMBIT/G  irtegers  (according  to  hint  variables  'smallest_integer' 
and  ' large stjlnteger ),  error  condition  'mul3'  is  signalled. 

The  error  messages  for  this  function  follow. 

mull:  The  first  argument  of  a  call  on  the  builtin 

"multiply"  is  "  ...  ",  which  is  not  of  type  "Integer". 

mul2:  The  second  argument  of  a  call  on  the  builtin 

"multiply"  is  "  ...  ",  which  is  not  of  type  "integer". 

mul3:  A  call  on  the  builtin  "multiply"  produced  a  product 

of  "  ...  ",  which  is  outside  of  the  range  of  integers. 
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divide  (read) 


This  function  is  called  with  two  tail  arguments  (ami  and  am  2)  and 

two  head  results  (resl  and  res  2).  It  is  used  to  produce:  as  result  real  the 

'integer'  node  representing  th9  quotient  of  the  integer  represented  by  the 

'integer'  node  ami  divided  by  the  integer  represented  by  the  'integer'  node 

'arg  2' ;  and  as  result  res  2  the  'integer'  node  representing  the  remainder  of 

that  division. 

• 

If  argl  is  not  of  type  'Integer',  error  condition  'dlvl'  Is  signalled. 

If  arg 2  Is  not  of  type  'Integer',  error  condition  'div2'  is  signalled.  If 
arg2  Is  'Integer  O',  error  condition  'dlv3'  Is  signalled.  If  the  quotient 
of  the  division  is  an  Integer  which  Is  outside  of  the  range  of  existing 
AMBIT/G  Integers  (according  to  hint  variables  'smallest_lnteger'  and 
'largest_lnteger'),  error  condition  *dlv4'  Is  signalled.  If  the  remainder 
of  the  division  Is  an  integer  which  Is  outside  of  the  range  of  existing 
AMBIT/G  Integers,  error  condition  'dlvS'  Is  signalled. 


The  error  messages  for  this  function  follow. 

divl:  The  first  argument  of  a  call  on  the  bulltln 

"divide"  Is  "...  ",  which  Is  not  of  type  "Integer". 

dlv2:  The  second  argument  of  a  call  on  the  bulltin 

"divide"  Is  "...  ",  which  Is  not  of  type  "Integer". 

div3:  A  call  on  the  bulltln  "divide"  is  an  attempt  to 

divide  by  zero. 

dlv4:  A  call  on  the  bulltin  "divide"  produced  a  quotient 

of  "  ...  ",  which  is  outside  of  the  range  of  integers. 

dlv5:  A  call  on  the  bulltln  "divide"  produced  a  remainder 

of  "  ...  ",  which  is  outside  of  the  range  of  integers. 
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sign  (read) 


This  function  is  called  with  one  tail  argument  (arg  1)  and  one  head 
result.  It  is  used  to  produce  as  result  either: 

a)  'integer  -1'  if  argl  is  an  'integer'  node  representing 

an  integer  less  than  zero;  or 

bT  'integer  O'  if  argl  is  'integer  O';  or 

c)  'integer  1'  if  argl  is  an  'integer'  node  representing 

an  integer  greater  than  zero. 

If  argl  is  not  of  type  'integer' ,  error  condition  'sgnl'  is  signalled. 

If  the  integer  result  (-1,  0,  or  1)  is  outside  of  the  range  of  existing  AMBIT/G 
integers  (according  to  hint  variables  'smallest_integer '  and  'largest_integer') , 
error  condition  'sgn2‘  is  signalled. 

The  error  messages  for  this  function  follow. 

sgnl:  The  argument  of  a  call  on  the  builtin  "sign" 

is  "  ..." ,  which  is  not  of  type  integer" . 

sgn2:  A  call  on  the  builtin  "sign"  produced  a  result 

of  "  ...  ",  which  is  outside  the  range  of  integers. 


A  SAMPLE  ERROF 

The  following  page  is  terminal  output  of  an  AMBIT/G  run  on  Multics 
which  causes  an  error  condition  (drfl) .  Following  the  listing  of  the  run  is 
a  listing  of  the  program  which  caused  the  error.  The  arrows  added  to  the 
output  indicate  lines  typed  in  by  the  user. 
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CHAPTER  7 


THE  DEBUGGING  FACILITY 


This  chapter  describes  'AMBIT/G  DEBUG' ,  henceforth  called 
'agd',  which  is  an  interactive  debugging  aid  used  in  conjunction  with  the 
AMBIT/G  Programming  System  implemented  on  Multics.  This  debugger 
gives  the  user  the  facility  to  examine  the  AMBIT/G  Data  Graph  symbolically 
in  a  variety  of  ways  and  to  alter  links  in  the  Data  Graph  on  an  individual 
basis. 


The  user  invokes  the  debugger  fcy  typing  the  following  command  line 
to  the  console  command  monitor: 

agd 

The  debugger  should  only  be  invoked  any  time  after  AMBIT/G  data  has  been 
initialized  (or  restored).  AMBIT/G  initialization  is  complete  after  the  second 
new  line  (carriage  return)  is  issued  by  the  AMBIT/G  System  when  it  is  first 
started.  If  'agd'  does  not  detect  any  existing  AMBIT/G  data  when  it  is 
started,  it  will  type  an  informative  error  message  and  terminate.  Otherwise, 
it  issues  a  new  line  (carriage  return)  and  waits  for  user  input. 

'agd'  is  used  interactively  at  a  typewriter  terminal  where  the  user 
types  requests,  and  the  debugger  issues  typed  responses  to  those  requests. 
It  never  takes  the  initiative  of  requesting  something  from  the  user,  'agd' 
continues  to  interpret  the  user's  requests  until  it  terminates  as  a  result  of 
the  user's  typing  either: 

a)  a  '/q '  command  to  quit,  or 

b)  a  '/S'  command  to  signal  a  system  status  save,  or 

c)  a  '/R*  command  to  resume  AMBIT/G  interpretation. 
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LEXICAL  CONVENTIONS 


SPACES  are  treated  as  characters  and  are  not  normally  optional 
in  'agd'  .  For  example,  a  full  node  name  must  have  at  most  one  SPACE 
separating  the  type-name  from  the  subname. 

Since  the  names  of  AMBIT/G  nodes  may  consist  of  any  printing 
characters,  the  following  conventions  apply  to  all  user-typed  input  to  'agd1. 

The  dollar  sign  '$'  serves  as  a  protection  character  for  whatever 
character  immediately  follows  it.  Unless  preceded  by  a  protective  dollar 
sign,  the  following  characters  have  special  meaning: 


Character  Meaning 


carriage  return 


/ 

& 

$ 


statement  terminator 
statement  terminator 
separator 

separator  and  command  indicator 
Internal  name  indicator 
protect  the  next  character 


When  a  carriage  return  is  protected  (because  a  line  ended  in  an 
unprotected  '$'),  both  the  '$'  and  carriage  return  are  ignored.  Thus,  this 
combination  can  be  used  to  input  a  statement  on  any  number  of  typed  lines. 


The  use  of  an  unprotected  '$'  immediately  preceding  any  of  the 
other  five  special  characters 

1  ,  /  &  $ 

causes  that  character  to  be  interpreted  literally  as  a  character  in  a  name. 
Thus ,  a  user  must  type 

ab$&$$cd 

when  referring  to  the  node  name  'ab&$cd*. 
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When  an  unprotected  '$'  Immediately  precedes  any  character  other 
than  the  special  ones,  that  '$'  is  ignored. 

The  above  conventions  for  user-typed  input  to  'agd'  insure  that 
a  user  may  make  unambiguous  requests.  These  conventions  only  apply  to 
input,  but  'agd'  output  may  be  ambiguous  in  some  rare  cases.  In  these 
cases  it  should  be  possible  for  a  user  to  type  one  or  two  requests  whose 
responses  will  eliminate  the  ambiguity. 

STATEMENTS 


A  statement  is  an  individual  request  which  a  user  types  to  'agd1. 

Usually  a  user  types  a  statement  immediately  followed  by  a  carriage  return. 

This  causes  'agd'  to  scan  the  statement  and  make  some  response.  Note, 
however,  that  'agd'  makes  a  null  response  to  the  null  statement. 

More  than  one  statement  may  be  Included  on  a  typed  line  by  using 
an  unprotected  as  a  statement  terminator. 

When  'agd'  detects  an  error  and  responds  to  a  statement  without 
having  scanned  to  the  ei.i  of  the  statement,  it  aborts  the  scan  for  the 
remainder  of  the  typed  line  and  Issues  an  extra  carriage  return  to  indicate 
this  condition  to  the  user. 

Except  for  the  null  statement,  a  statement  is  either  a  command, 
or  it  is  a  request  to  examine  part  of  the  AMBIT/G  Data  Graph.  Examination 
may  result  in  a  typeout  of  the  origin,  name,  and  destination  of  a  particular 
link;  or  it  may  produce  such  a  typeout  for  each  link  emanating  from  a 
particular  node . 

If  'agd*  detects  an  error  in  a  statement,  it  attempts  to  respond 
with  an  Informative  error  diagnostic.  There  are  so  many  possible  diagnostics 
which  may  be  issued  that  this  writeup  will  not  include  a  list  of  them.  The 
sample  session  at  the  end  of  the  chapter  includes  examples  of  these  diagnostics. 

Before  presenting  the  various  forms  of  statements ,  some  definitions 
and  conventions  will  be  given  which  apply  to  many  of  the  statements. 
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Node  Names 


AMBIT/G  Data  consists  of  nodes  and  links.  Each  node  belongs  to 
a  class,  where  each  member  of  that  class  has  the  same  links  defined.  This 
membership  is  described  as  the  type  of  a  node.  The  type  of  any  given  node 
never  changes,  and  contributes  directly  to  the  node's  name. 

The  type  or  type-name  is  that  character  string  which,  together 
with  a  node's  subname,  makes  up  the  full  name  of  a  node.  However,  some 
nodes  have  no  subname  (those  located  with  a  null  name);  such  a  node  is 
unnamed.  A  node  with  a  non-null  subname  is  a  named  node. 

Thus,  each  node  in  AMBIT/G  Data  has  a  type-name  which  consists 
of  one  or  more  printable  ASCII  characters  (not  including  SPACE#  TAB,  etc.). 
Each  named  node  also  has  a  subname  which  consists  of  one  or  more  printable 
ASCII  characters  (not  including  SPACE,  TAB,  etc.).  The  subnames  of  the 
nodes  of  a  given  type  must  be  unique.  The  canonical  graphical  representation 
of  a  named  node  is  a  rectangular  box  with  the  type-name  positioned  above 
the  subname  within  the  box.  In  'agd' ,  a  node  name  is  typed  as  the  type-name 
followed  by  one  SPACE  followed  by  the  subname. 

Each  type  in  AMBIT/G  data  has  an  associated  node  of  type  'type' 
with  a  subname  corresponding  to  the  associated  type.  For  example,  if 
'integer  5'  is  a  node  name,  its  type  or  type-name  is  'integer*  and  its  subname 
is  '5'.  Furthermore,  there  must  also  be  a  node  in  the  data  whose  name  is 
'type  integer'.  This  implies  there  must  be  a  node  in  the  data  whose  name  is 
'type  type',  and  this  sequence  of  Implications  stops  here. 

Internal  Subnames 


For  the  purposes  of  using  'agd'  to  examine  AMBIT/G  Data  which 
Includes  unnamed  nodes,  the  convention  has  been  established  to  associate  an 
internal  subname  with  every  node.  An  internal  subname  begins  with  an  un¬ 
protected  and  that  is  followed  directly  by  an  unsigned  or  negative  decimal 
Integer.  The  integer  part  of  an  internal  subname  of  a  given  node  conveniently 
coincides  with  the  Integer  representing  that  node  in  the  Pl/l  representation  of 
AMBIT/G  Data  in  the  Multics  Implementation;  this  is  particularly  valuable  for 
debugging  the  AMBIT/G  System  in  conjunction  with  the  Multics  'debug'  command. 


102 


Note  that  the  integer  part  of  an  Internal  subname  may  be  any 
negative  Integer  greater  than  some  lower  bound  which  depends  upon  the 
particular  AMBIT/G  run.  There  is  a  similar  upper  bound  for  those  internal 
subnames  whose  Integer  ports  are  positive;  however,  within  the  positive 
range  not  all  integers  correspond  to  nodes.  A  node  with  n  links  (n  ss  0) 
will  "use"  n  consecutive  Integers.  A  type  node  "uses"  four  consecutive 
Integers . 


A  node  with  an  internal  subname  whose  Integer  part  is  negative 
is  a  terminal  node;  i.e. ,  it  has  no  links. 

1/plng  Node  Names 

When  'agd'  types  out  a  node  name .  it  types  a  type-name  followed 
by  a  SPACE  followed  by  a  subname.  For  a  named  node,  the  subname  typed  is 
the  subname  of  that  node;  and  for  an  unnamed  node,  the  subname  typed  is  the 
internal  subname  of  that  node. 

When  a  user  wishes  to  type  in  a  reference  to  a  node  by  its  node  name  he 
has  some  choices:  the  usar  may  type  either  two  names  separated  by  one 
SPACE,  or  Just  one  name.  If  he  types  two  names,  the  first  is  taken  as  a  type- 
name.  and  the  second  as  a  subname,  'agd1  will  allow  the  type-name,  in  this 
case,  to  be  the  internal  subname  of  a  'type'  node.  The  second  name  typed  by 
a  user  may  be  either  the  subname  of  a  node  or  an  internal  subname;  either  form 
is  acceptable  for  a  named  node,  but  the  former  option  could  not  be  used  for 
an  unnamed  node. 

If  the  user  types  a  node  name  consisting  of  Just  one  name .  that  name 
is  taken  as  a  subname,  'agd'  will  accept  that  reference  if  the  typed  subname 
is  the  subname  of  only  one  node  in  the  data.  This  will  always  be  the  case 
when  an  internal  subname  is  typed. 

Therefore,  when  a  user  refers  to  a  node,  he  may  type  only  its  Internal 
subname.  If  he  precedes  that  by  a  type-name,  'agd'  checks  for  consistency. 

On  type  out.  'agd'  will  not  eliminate  the  type-name  in  a  node  name. 
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Link-Names 


A  link  in  AMBIT/G  Data  is  basically  a  triplet  of  node  names,  where 
the  elements  are:  origin,  name,  and  destination.  Although  the  'name'  of  a 
link  is  just  another  node,  a  convention  has  been  established  for  typing  out 
and  typing  in  link-names  which  is  different  from  the  conventions  for  typing 
node  names. 

When  'agd'  types  out  a  link-name  it  omits  typing  the  type-name 
and  separating  SPACE  when  the  type-name  is  "link";  otherwise,  the  node 
name  for  that  link  is  typed.  Since  many  names  of  links  are  of  type  'link', 
this  convention  reduces  type-out  time. 

This  convention  also  applies  to  a  user-typed  link-name.  Thus,  if 
only  one  name  is  typed  as  a  link-name,  and  if  it  is  not  an  internal  subname, 
then  'agd'  assumes  the  user  had  also  typed  a  type-name  of  "link" .  If  the 
user  types  just  an  Internal  subname,  the  node  which  is  uniquely  named  by  that 
internal  subname  is  taken  as  the  link-name  reference. 

Link  Type-Out 

When  'agd'  types  out  one  or  more  links  it  first  types  out  the  node 
name  of  the  origin  of  the  llnk(s)  followed  by  a  colon.  Then  on  separate  lines, 
it  types  each  link  Indented  by  one  TAB.  The  link-name  is  typed  followed  oy 
a  '/'  as  separator.  This  is  normally  followed  by  the  node  name  of  the 
destination  of  the  .Unk.  One  special  convention  has  been  established  to 
conserve  type-out  time  and  aid  to  readability;  if  the  destination  is  the  built- 
in  undefined  node,  ’undef  undef',  the  tvoe  out  of  that  node  name  is  omitted. 

There  is  no  similar  convention  for  typing  in. 
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STATEMENT  FORMS 


The  most  common  'agd'  request  Is  for  the  examination  of  a  node 
or  a  link.  The  following  syntactic  forms  may  be  used: 

Syntactic  Form  Use 

node -name  to  examine  a  node 

node-name  {  /  link-name  }  /  to  examine  a  node 

node-name  {  /  link- name  }  /  link-name  to  examine  a  link 

A  matching  pair  of  curly  braces  indicates  they  enclose  a  cot:  struct  which 
may  be  repeated  any  number  of  times,  including  zero.  The  uiiderllned 
strings  are  meta-variables  (non-terminals);  their  definitions  have  already 
been  given. 

The  only  SPACES  allowed  in  these  statements  are  those  which 
separate  a  type-name  from  a  subname.  A  V  may  optionally  be  used  in  place 
of  a  '/'  in  these  statements.  Examination  of  a  node  means  that  'agd'  types 
out  all  links  which  emanate  from  the  specified  node.  If  just  one  node  name 
is  given,  as  in  the  first  form  above,  that  name  refers  to  the  specified  node. 

A  statement  of  the  second  form,  however,  permits  the  user  to  type  a  list  of 
link-names  to  specify  a  "walk"  through  the  AMBIT/G  Data  Graph  to  reach  the 
specified  node.  Each  given  link-name  is  interpreted  as  a  step  out  of  the 
current  node  via  that  link  to  the  node  at  the  destination  of  that  link;  that 
destination  node  then  becomes  the  current  node. 

A  statement  of  the  third  form  is  used  to  examine  just  one  link  of 
a  specified  node,  'agd'  interprets  such  a  statement  by  first  determining  the 
origin  in  the  same  manner  as  it  does  for  a  statement  of  the  second  form.  Then, 
the  final  link- name  given  determines  the  one  link  which  'agd'  will  type  out. 

As  'agd'  scans  a  statement,  Interpreting  a  "walk",  it  checks  for 
any  error  conditions  and  will  report  immediately  on  any  error  without  continuing 
its  scan. 
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Commands 


The  remaining  statement  forms  are  commands  which  begin  with  a 
'/'  followed  by  a  letter.  The  following  commands  are  recognized  by  'agd': 


Syntactic  Form 

ljse_ 

/t 

type -name 

type  out  £ype  statistics 

A 

type-name 

.list  all  Jinks  of  the  type 

A 

node- name 

type  .Internal  subname 

/s 

node-name/llnk-name/node-name 

jet  a  link  (same  as  /w) 

/w 

node-  name/link-name/  node-name 

write  a  link  (same  as  /s) 

/S 

glgnal  System  Status  gave  and 
resume  execution 

/R 

.resume  AMBIT/G  Interpretation 

/q 

<jult 

The  '/S'.  '/R’,  and  '/q1  commands  must  be  given  as  Just  two  characters 

The 

other  commands  may  have  any  number  (Including  0}  of  SPACES  following 

the  first  two  characters.  The  argument  of  a  '/t'  or  '/l'  command  cannot  be 
an  Internal  subname. 

The  '/t'  command  causes  'agd'  to  type  out  the  current  and  maximum 
numbers  of  links  and  nodes  for  the  given  type  and  also  the  Internal  subnames 
spanned  by  the  current  number  of  nodes. 

The  '/V  command  causes  'agd1  to  type  out  the  node  name  of  the 
given  node  followed  by  a  followed  by  the  Internal  subname  of  that  node. 

The  '/s'  or  '/w'  command  alters  the  AMBIT/G  Data  and  types  out 
both  the  old  and  new  values  of  the  link. 

The  '/S'  and  '/R'  commands  provide  user  control  of  the  AMBIl/G 
System  which  are  not  directly  related  to  debugging.  Their  use  Is  described 
elsewhere  In  the  report. 

The  '/q'  causes  'agd'  to  terminate  and  return  to  Its  caller. 
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A  SAMPLE  SESSION 


This  description  of  'agd'  concludes  with  a  sample  session  of  using 
the  debugger  on  a  limited  part  of  an  AMBIT/G  Data  Graph.  The  listing 
included  is  a  real  session  without  any  simulated  typing.  For  convenience 
in  the  references  to  the  listing,  it  has  been  annotated  to  the  extent  that 
every  line  typed  in  by  the  user  has  an  associated  integer;  all  other  lines 
are  typed  out  by  the  system. 

On  the  next  page  is  a  portion  of  the  AMBIT/G  Data  Graph  which 
is  referenced  in  the  sample  session.  The  Data  Graph  referenced  also  in¬ 
cludes  all  initial  (or  built-in)  data. 

Following  that  is  a  listing  of  the  session,  and  that  is  finally 
followed  by  an  explanation  of  the  session. 

Other  'agd'  sessions  are  Included  among  the  examples  in  Volume  II. 
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Aftlng  of  the  Session 


ciiarcofin  free 
charconn  free:: 

next/cliarconn  «59l2 
vnl  uii / 

charconn  NS:)  02 
ciiarcoiin  u!>JE2: 

next/ chn rconii  N  Li !)  C  4 
value/char  * 

NiiDOL 

clicirconn  R!i9ii4: 

luixt/chnrconn  NSikN, 
value/char  a 

i  i  J  'J  u  J 

internal  subnan.e  do f.s  wot  nm;;e  a  node 

charconn  free/ next /next /next/ 
cfiarcurm  rt!> :}oii: 

•  text/charconn  N3GC4 
'Ail  ue/char  ; 

char  ; 

TliC  NODE  iiAi.1:  "char"  ii/.S  DAD  SYNTAX  NR7  SPACES 
char 

char  NO  LINKS 
froe;/l  char;/lchnrconn 

"free"  IN  NOT  Uii  I  OWE:  cell#  pipe#  circle,  chnrconn 
NODES  OF  TYPE  "char"  WAVE  NO  LINKS 
NODES  OF  TYPE  "chnrconn"  HAVE  LINKS: 
next 
vn  1  uo 

/t  chnrconn;/!  chnrconn;/s  charconn;/n  charconn 
TYPE  "charconn"  HAS  2/2  LINKS  AND  2S03/2003  NODES:  NO .32  T.. 
type  charconn  ■  NlCiS  2 
I iiCOI iPLETE  "/s"  COf'JiA.ID 


/q  charconn 

USE  "/q"  ALONE  TO  WIT 

charconn  AIDS 2 

INTERNAL  SURNAiiE  "iil0r»2"  DOES  HOT  NAME  A  NODE  OF  TYPE  "charconn" 
type 

INTERNAL  SURNAME  "G1.0S2"  HAS  BAD  SYNTAX 
type  ulOS 2 

type  charconn:  NO  LINKS 
foo;iiOO  rioo 

110  NODE  HAS  SURNAME  "foo" 

THE  TYPE  NODE  "noo"  IS  UNDEFINED 
type  poo 

"poo"  IS  NOT  A  SURNAME  OF  A  NODE  OF  TYPE  "type" 

/s  charconn  NSOGO/val ue/char  3P 
charconn  n.S'JCG: 

value/char  ; 

BECOMES  va luc/char  SP 
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18 


circle  r;clrcln  r / 1  Ink  value 
cl rclo  r: 


value/ rule  start 

cl rcle  r: 

valuo/rule  start 


19 

circle  r, va 1 uc, state 
rule  start: 

statc/flaL  clear 

20 

circle  r/ value/ next 

NODE  "rule  start"  DOES  NOT 

HAVE 

LI NK  "1  ink  next" 

21 

circle  r/val ue/ state/ 

Tlau  clear:  NO  LI. 'IKS 

22 

circle  r/val ue/ state/ state 
NODE  "fins  clear"  DOES  NOT 

HAVE 

LINK  "link  state"; 

23 

circle  r/f uo 

"foo"  18  NOT  A  :>UBi!AME  OF  A 

ilODE 

OF  TYPE  "link" 

24 

/q 

r  1822  !l..n;7  25  G  +  lj  jl 

HAS  i  10. ' E 
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Explanation  of  the  Session 


1.  "agd"  is  the  command  the  user  typed  to  the  Multlcs  console 
command  monitor  which  caused  'agd'  to  be  invoked.  Note  the 
blank  line  issued  by  'agd'  to  indicate  it  is  ready  to  receive  requests. 

2.  This  is  a  request  to  examine  a  node.  Note  that  'agd'  retyped 
"charconn  free:"  and  then  typed  the  two  links  emanating  from 
that  node.  Since  the  names  of  both  links  are  of  type  'link' , 

"link"  is  not  typed  in  the  link-names.  Also,  since  the  destination 
of  the  'value'  link  is  'undef  undef'  nothing  was  typed  there.  The 
destination  of  the  'next'  link  is  an  unnamed  node,  and  therefore 
an  internal  subname  is  typed. 

3.  This  is  a  request  to  examine  a  node  using  a  node  name  composed 
of  a  type-name  and  internal  subname. 

4.  Just  the  internal  subname  was  typed  by  the  user  to  examine  a  node. 

5.  Just  an  internal  subname  was  typed,  but  it  does  not  name  a  node. 

6.  This  is  an  examination  of  a  node  by  specifying  a  "walk".  Note 
the  syntax  of  the  destination  of  the  'value'  link. 

7.  The  user  then  tried  to  examine  the  node  "char;" ,  but  the  ';'  acted 
as  a  statement  terminator. 

8.  This  is  a  successful  examination  of  that  node,  demonstrating  the 
use  of  the  protection  character. 

9.  Three  statements  are  included  on  one  typed  line.  First,  there  is 
an  attempt  to  examine  a  node  by  typing  only  a  subname,  but  that 
subname  is  not  unique;  note  that  'cell  free',  'pipe  free',  and 
'circle  free'  are  built-in  nodes.  Then  there  are  two  examples  of 
the  '/l'  command. 
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10.  This  line  includes  four  statements.  The  first  is  an  example  of  the 
'/t'  command,  and  the  second  is  an  example  of  the  '/i'  command, 
'agd'  detected  an  error  in  the  third  statement,  and  terminated  its 
scan,  which  is  indicated  by  its  issuing  the  blank  line. 

11.  The  user  now  re-enters  (for  demonstration  only)  the  command  which 
was  not  previously  scanned,  but  'agd'  detects  an  error  and  again 
terminates  its  scan  in  the  middle  of  the  line. 

12.  The  user  has  typed  a  node  name,  where  the  type-name  is  not 
consistent  with  the  type  of  the  typed  internal  subname. 

13.  The  typed  input  appears  to  be  correct,  but  due  to  a  terminal  or 
communications  problem  an  extra  period  was  accidentally  entered. 
(Incidentally,  this  was  a  spontaneous  error  which  the  author  did 
not  expect.) 

14.  This  is  an  example  of  the  examination  of  a  'type'  node. 

15.  Two  silly  commands  are  typed  by  the  user,  and  'agd'  types  the 
two  error  diagnostics. 

16.  This  is  another  example  of  an  error  diagnostic  caused  by  an  incorrect 
node  name. 

17.  This  is  an  example  of  setting  a  link. 

18.  This  line  Includes  both  a  node  examination  and  a  link  examination 
which  both  produce  identical  results.  The  second  statement 
includes  a  link-name  which  was  typed  with  a  type-name. 

19.  This  is  a  link  examination  with  a  "walk”,  and  also  demonstrates 
the  use  of  commas  as  separators. 
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20.  This  is  a  node  examination  which  includes  a  "walk"  ending  in 
a  non-existant  link. 

21.  This  is  a  successful  node  examination. 

22.  This  is  a  link  examination  which  includes  a  "walk"  ending  in 
a  non-existant  link  on  a  terminal  node. 

23.  This  is  an  attempt  to  examine  a  link  where  the  ILnk-name  is  not  even 
a  node. 

24.  This  is  a  successful  end  of  the  session.  The  final  'ready' 
message  line  was  typed  by  the  Multics  system.  It  indicates 
that  this  sample  session  used  9.867  seconds  of  CPU  time. 
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CHAPTER  8 

THE  IMPLEMENTATION 


This  chapter  begins  with  credits  and  acknowledgements  of  those  re¬ 
sponsible  tor  the  implementation  of  the  AMBIT/G  System  on  Multics.  The 
remainder  oi  the  chapter  discusses  various  details  of  the  implementation 
which  serve  as  notes  for  a  maintainer  of  the  system  and  as  a  guide  for  using 
the  system.  Since  at  the  time  of  this  writing  there  is  essentially  no  user 
community  for  this  experimental  implementation,  we  have  not  produced  a 
polished  user  manual.  The  implementation  was  written  in  Multics  PL/I  and 
AMBIT/G  (bootstrapped  by  hand-translation  into  PL/I). 
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"General  Electric"  645  computer  system. 

This  development  was  carried  our  using  a  semi-portable  Datel  30  type¬ 
writer  terminal  especially  modified  for  Multics  use.  This  terminal  was  used  in 
the  Wakefield  office  of  Applied  Data  Research  and  in  a  home  of  one  of  the 
implementors.  We  regularly  obtained  line  printer  listings  by  ordering  them 
(using  the  terminal)  and  then  picking  them  up  at  M.I.T. 
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whole.  Carlos  Christensen,  D.  Austin  Henderson,  Michael  J.  Fischer,  arid 
M.S.  Wolfberg  worked  together  to  produce  the  design  of  the  language  to  be 
implemented  and  to  resolve  some  difficult  problems  of  the  implementation. 

M.J.  Fischer  wrote  the  AMBIT/G  program  for  the  interpreter  which  appears  in 
the  third  volume  and  wrote  several  of  the  example  programs  in  the  second 
volume.  M.S.  Wolfberg  wrote  the  loader,  the  underlying  foundation  described 
in  the  current  chapter,  the  debugging  subsystem,  and  the  remaining  example 
programs  with  the  assistance  of  Maynie  Ho. 
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AN  INTFR.JAI.  VIEW  OF  THE  MULTICS  AMBIT/G  SYSTEM 


An  AM  BIT /G  program  exists  on  Multics  as  a  pair  of  source  files; 
for  example,  the  program  ‘foo1  would  be  represented  by  'foo. hints'  and 
'foo.ambitg' .  The  file  with  secondary  name  'hints'  is  usually  rather  small; 
it  includes  some  information  which  causes  a  particular  initialization  of  the 
AMBIT  G  machine.  Since  this  information  is  considered  to  be  outside  of  the 
definition  of  the  AMBIT/G  language  we  call  its  contents  "hint  information" 
or  just  "hints" .  The  syntax  and  semantics  of  the  hints  is  given  elsewhere. 

The  source  file  with  secondary  name  'ambitg'  includes  a  string  en- 
codement  of  the  AMRIT/G  program  in  a  format  acceptable  to  the  AMBIT/G 
loader. 


The  AMBIT/G  System  exists  as  eight  executable  segments:  'pribin', 
'interpreter',  'loader',  'ambitg_error' ,  'intldr_error' ,  'agd',  'agsave',  and 
'agrestore'.  At  a  minimum,  the  first  three  segments  must  be  available  for 
execution,  and  the  next  three  segments  should  be  available  in  case  any 
error  conditions  arise.  The  remaining  two  segments  are  used  only  for  saving 
and  restoring  the  status  of  an  AMBIT/G  program.  Although  'agd'  is  required 
for  handling  errors ,  it  alone  is  required  for  performing  interactive  symbolic 
debugging  of  AMBIT/G  data. 

The  AMBIT/G  System  can  be  invoked  to  run  a  program  by  the  user's 
typing  the  console  command  "ambitg"  followed  by  a  space  followed  by 
the  name  of  the  program.  Alternatively,  the  'ambitg'  procedure  can  be  called 
from  within  a  PL/I  program  with  one  character  string  argument  as  the  name  of 
the  program.  The  'ambitg'  procedure  is  part  of  the  'pribin'  bound  archive, 
and  the  'pribin'  segment  has  'ambitg'  as  an  additional  name. 

Let  us  assume  the  user  issued  the  console  command  "ambitg  foo". 

We  shall  now  trace  through  the  initialization  process. 
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Initialization 


First,  the  system  save  switch  is  cleared.  Then  an  attempt  is  made 
to  "open"  the  source  file  'foo.ambitg'  in  the  current  working  directory;  if 
there  is  an  error  an  error  message  is  typed  and  executio'  aborts.  The  length 
of  this  file  is  determined  as  a  character  count,  and  the  file  input  counter  is 
initialized  to  zero. 

To  overcome  the  inability  of  Multics  PL/I  to  read  a  file  whose  name 
has  been  determined  by  a  computation,  a  fixed  name,  'ambitg_hints' ,  is 
temporarily  added  to  the  hint  file,  'foo. hints'.  PL/I  input  statements  are 
used  to  read  the  hint  file.  If  the  fixed  name  cannot  be  added  to  the  hint  file 
for  any  reason,  an  indicative  error  message  is  typed  concerning  the  "opening" 
of  the  hint  file  and  execution  aborts . 


Three  segments  are  then  created  in  the  current  process  directory 
which  are  to  contain  nearly  all  data  specific  to  this  AMBIT/G  run; 


Name 

nodes_segment 

names_segment 

defns_segment 


Use 

all  AMBIT/G  'type'  nodes  and  non¬ 
terminal  nodes 

the  symbol  table  of  all  named  nodes 
all  function  definitions 


If  one  of  these  segments  is  found  to  be  already  known  to  the  process,  it  is 
used  and  initially  truncated.  Any  error  condition  causes  an  indicative  error 
message  to  be  typed  and  execution  aborts. 

If  all  has  gone  well  up  to  this  point  "AMBIT/G"  is  typed  on  the  ter¬ 
minal  as  positive  feedback  to  the  user. 


Default  values  are  assigned  to  the  hint  variables  and  then  a  'get 
file  data'  PL/l  statement  is  used  to  read  any  overriding  values  for  the  hint 
variables.  Consistency  checks  are  performed  for  hint  variables  to  meet 
various  conditions.  Any  inconsistency  causes  an  indicative  error  message 
to  be  typed  and  execution  aborts . 
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After  passing  all  consistency  checks,  the  initializer  reads  any  number 
of  terminal  node  hints  from  the  hint  file.  Each  such  hint  consists  of  a  non¬ 
null  string  and  a  non-negative  integer.  The  end  of  these  terminal  node  hints 
is  signalled  by  a  null  string.  The  given  hints  are  merged  with  built-in  ter¬ 
minal  node  hints. 

Then  any  number  of  non-terminal  node  hints  are  read  from  the  hint 
file.  Each  such  hint  consists  of  a  non-null  string  and  an  integer  greater 
than  zero  and  a  non-negative  integer.  The  end  of  these  non-terminal  node 
hints  is  signalled  by  a  null  string.  The  given  hints  are  merged  with  built-in 
non-terminal  node  hints. 

During  the  reading  of  hints  various  conditions  may  cause  an  error 
message  to  be  typed  and  execution  to  be  aborted.  Otherwise,  the  hint  file 
is  "closed"  by  removing  the  temporary  name  'ambitg_hints'  from  it.  This 
too  is  prone  to  an  error  condition  leading  to  execution  aborting. 

If  all  is  well,  the  user  is  given  more  feedback  by  a  blank  line  being 

typed. 


At  this  point,  the  'nodes_segment'  is  arranged,  and  all  built-in  nodes 
are  created  and  their  names  are  made  known  in  the  'names_segment' .  Then 
the  'defns_segment'  is  initialized  to  include  definitions  of  all  built-in  functions. 
All  built-in  links  are  defined,  and  finally  an  initial  data  graph  is  created  in¬ 
cluding  various  built-in  rules  in  a  'clear'  state. 

A  second  blank  line  is  typed  to  indicate  to  the  user  the  end  of  ini¬ 
tialization.  The  AMBIT/G  interpreter  is  then  invoked  to  begin  interpretation 
at  'rule  start'  ,  which  is  one  of  the  built-in  rules. 

Interpretation 


The  initializer  creates  an  AMBIT/G  machine  and  data  graph  and  finally 
calls  the  interpreter  as  a  subroutine  with  one  argument.  In  this  case,  that 
argument  is  'rule  start'.  Thus  the  interpreter  carries  out  an  interpretation 
cycle  on  'rule  start'.  Since  that  rule  is  in  a  'clear'  state  ,  it  is  first  compiled 
and  then  is  interpreted.  The  contents  of  that  rule  causes  a  function  call  on  the 
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AMBIT/G  loader.  The  loader  reads  its  input  one  character  at  a  time  from 
the  source  file  'foo.ambitg'  by  calling  on  the  primitive  'read_char'.  When 
a  '-start-'  statement  is  processed  by  the  loader,  it  returns  control  to  the 
interpreter  which  finishes  its  interpretation  of  'rule  start'.  That  interpre¬ 
tation  causes  the  'success'  exit  of  'rule  start'  to  be  the  starting  rule  of  'foo'. 
So  the  interpreter  will  then  carry  out  an  interpretation  cycle  on  that  rule. 

The  interpreter  then  continues  to  execute  the  program  'foo'  by  inter¬ 
preting  its  rules.  It  is  possible  that  'foo'  includes  rules  which  cause  further 
reading  of  'foo.ambitg'  by  either  calling  the  loader  again  or  by  calling  the 
read  version  of  the  builtin  'char'. 

Interpretation  continues  indefinitely  until  one  of  the  following  occurs: 

a)  The  interpreter  detects  an  error  condition;  this  causes  an 
error  message  to  be  typed  and  execution  aborts. 

b)  The  interpreter  calls  a  primitive  which  detects  an  error 
condition;  this  causes  an  error  message  to  be  typed  and 
execution  aborts. 

c)  The  interpreter  interprets  'rule  stop'  at  the  top  level  (i.e. , 

'ptr  ret'  points  to  'rule  stop');  this  causes  the  interpreter 
to  return  control  to  its  caller.  If  the  interpreter  had  been 
called  by  the  initializer,  the  initializer  then  returns  control 
to  its  caller  which  was  probably  the  console  command  moni¬ 
tor.  This  is  the  standard  ending  of  a  complete  AM3IT/G  run. 

The  AMBIT/G  data  is  preserved  in  the  process  directory. 

d)  The  interpreter  detects  the  system  save  switch  is  set  when 
it  begins  a  new  cycle  at  its  own  'rule  start';  this  causes 
the  interpreter  to  call  the  'agsave'  procedure  which  saves 
the  status  of  the  AMBIT/G  System  in  the  current  working 
directory.  The  'agsave'  procedure  returns  to  its  caller  with 
a  cleared  system  save  switch  if  the  user  answers  "yes''  to 
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the  question  "CONTINUE  EXECUTION?  "  typed  on  the  ter¬ 
minal;  this  causes  the  interpreter  to  begin  that  new  cycle 
from  which  it  was  interrupted.  If  the  user  had  answered 
"no"  to  the  question  posed  by  the  'agsave'  procedure,  then 
it  does  not  return  to  the  interpreter,  but  instead  calls  the 
console  command  monitor.  Thus  this  could  be  considered 
as  the  end  of  a  partial  AMBIT/G  run.  Note  that  the  AMBIT/G 
data  is  preserved  in  the  process  directory  in  addition  to  the 
saved  data  in  the  current  working  directory.  The  rule  which 
the  interpreter  was  about  to  interpret  is  saved  as  the  node 
pointed  to  by  'circle  r' . 

The  system  save  switch  is  originally  cleared  as  the 
first  action  performed  by  the  initializer.  The  user  can  cause 
that  switch  to  be  set  by  temporarily  interrupting  his  job  and 
invoking  the '/S'  command  of  'agd1. 

e)  The  user  aborts  the  running  of  the  job  by  depressing  the 
"QUIT"  button  on  his  terminal  and  does  not  resume  that  job; 
this  could  be  considered  as  the  end  of  a  partial  AMBIT/G 
run.  Note  that  AMBIT/G  data  is  preserved  in  the  process 
directory. 

f)  The  system  crashes  and  automatically  logs  out  the  user; 
this  destroys  the  process  directory  and  thus  all  AMBIT/G 
data.  If  the  user  had  caused  any  system  saves  to  be  done, 
the  working  directory  at  the  time  of  that  save  contains  the 
saved  data.  Thus  if  a  user  has  invested  in  a  rather  long  or 
costly  run,  he  is  advised  to  save  the  AMBIT/G  system 
status  at  appropriate  intervals  during  the  run. 

We  have  described  the  way  in  which  the  interpreter  is  called  as  a 
procedure  by  the  initializer  after  all  initialization  is  complete.  The  one  other 
call  upon  the  interpreter  in  the  current  implementation  is  in  'agrestore',  the 
restoration  procedure.  This  call  can  be  invoked  by  various  methods,  but  it 
finally  calls  upon  the  interpreter  with  an  argument  of  the  node  pointed  to  by 
'circle  r'. 
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Loading 


The  AMBIT/G  loader  Is  a  primitive  of  the  system  as  are  'read_link‘ 
and  'read_type'.  However,  it  differs  from  all  other  primitives  in  the  method 
used  to  define  and  implement  it.  The  loader  was  written  in  AMBIT/G  and 
then  hand-translated  to  PL/l  in  the  same  way  the  interpreter  was  implemented. 
Even  though  the  loader  is  a  primitive,  it  makes  use  of  calling  upon  many 
other  primitives,  but  then  so  do  some  of  the  other  primitives. 

If  the  loader  is  given  a  large  source  file  to  load  it  may  require  a 
significant  amount  of  time.  Thus  if  a  user  causes  the  setting  of  the  system 
save  switch  during  the  interpretation  of  a  rule  which  includes  a  call  on  the 
loader,  he  may  have  to  wait  a  long  time  before  the  interpreter  again  begins 
another  cycle  when  it  causes  the  saving  to  occur. 

The  loader  has  no  argument,  but  it  is  called  as  a  function  by  the 
interpreter.  The  result  is  a  'rule'  node  specified  in  the  'start'  statement 
which  ends  the  loading  process. 

Although  the  loader  detects  and  reports  several  error  conditions  re¬ 
sulting  from  an  improper  source  file,  there  are  some  errors  which  show  up 
in  a  primitive  on  which  the  loader  calls.  Unfortunately  the  error  message 
in  this  case  often  does  not  include  enough  information  for  the  user  to  deter¬ 
mine  the  cause  of  the  error.  In  this  case,  the  user  can  invoke  'agd'  and 
determine  the  current  statement  number  by  observing  the  destination  of  the 
'value'  link  of  'circle  page';  the  name  of  the  current  page  is  a  list  of 
characters  beginning  at  the  destination  of  the  'value'  link  of  'circle  line'. 
These  two  pieces  of  information  are  typed  as  part  of  any  error  message  which 
the  loader  itself  caused  to  be  typed. 

Errors 


When  the  interpreter  or  loader  detects  an  error  condition  it  makes 
a  procedure  call  on  an  error  procedure  in  the  object  segment  'intldr_error' . 
Entry  point  names  for  errors  detected  by  the  interpreter  are  'intldr_error  $  intN' 
where  N  is  a  decimal  integer.  Similarly,  loader  errors  use  entry  points  names 
of  the  form  'intldr_error$  IdrN'  .  Depending  on  the  type  of  error,  some  argu¬ 
ments  are  passed  to  the  particular  routine.  Each  error  routine  causes  the 
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typing  of  an  error  message  on  the  user's  terminal.  Arguments  are  converted 
to  symbolic  node  names  for  more  informative  type-out  by  the  error  routine's 
calling  'agd  $  get_name'  which  is  a  special  entry  point  in  the  debugger. 

Errors  detected  by  the  loader  cause  an  additional  line  to  be  typed 
before  the  specific  error  message  which  indicates  a  statement  number  and 
the  name  of  the  current  page  being  loaded.  These  are  determined  by  following 
the  'value'  link  of  'circle  page'  to  an  integer  and  the  'value'  link  of  'circle  line' 
to  a  list  of  characters. 

Following  the  specific  error  message  is  a  general  dump  of  the  status 
of  the  interpreter.  First  is  the  name  of  the  rule  being  interpreted  determined 
by  following  the  'value'  link  of  'circle  r' .  Then*  if  the  'value'  link  of  'circle  1' 
poirjts  to  a  'linkrep'  node  on  the  'contents'  list  of  the  current  rule,  that 
'linkrep'  is  dumped  as  completely  as  possible.  Finally*  if  \ptr  ret'  does  not 
point  to  'rule  stop'  a  function  call  stack  trace  is  performed  until  either 
'rule  stop'  is  encountered  or  a  cycle  is  encountered  or  the  list  is  found  to 
include  a  node  whose  type  is  not  'rule'.  The  trace  consists  of  typing  sub¬ 
names  of  'rule'  nodes  and  perhaps  ’  ...  'to  indicate  a  cycle,  or  a  full  node 
name  if  a  node  is  found  on  the  list  whose  type  is  not  'rule'. 

After  a/:  of  the  typing,  the  error  routine  calls  the  console  command 
monitor. 


When  a  primitive  other  than  the  loader  detects  an  error  condition, 
it  makes  a  procedure  call  on  an  error  procedure  in  the  object  segment 
'ambitg_error' .  These  various  error  routines  operate  just  as  those  in 
'intldr_error' . 

Saving 


The  system  save  switch  is  a  'fixed  binary  external  static'  variable 
which  is  cleared  at  the  beginning  of  AMBIT/G  initialization.  It  can  be  set 
by  the  user's  temporarily  interrupting  his  job  by  depressing  the  "QUIT" 
button  on  his  terminal  and  then  invoking  the  '/S'  command  of  'agd'.  Such  an 
invocation  may  be  carried  out  in  one  of  two  ways: 
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a)  The  user  may  enter  the  'agd'  debugger  by  typing  the  console 
command  “agd".  Then  he  may  use  various  features  of  the  de¬ 
bugger.  When  he  wishes  to  signal  a  system  save  and  con¬ 
tinue  execution,  he  types  the  'agd'  command  "/S". 

b)  The  user  may  type  the  console  command  "agd$S",  which  is 
equivalent  to  typing  "agd"  and  then  "/S", 

Either  of  these  operations  sinply  causes  the  system  save  switch  to  be  set 
and  then  interrupted  AMBIT/G  execution  to  be  resumed  by  calling  the  'start' 
procedure  of  the  Multics  Standard  Service  System. 

Actual  saving  will  then  occur  when  the  interpreter  is  about  to  begin  it 
next  interpretation  cycle.  Before  the  interpreter's  'rule  start'  is  executed,  ii 
the  system  save  switch  is  set,  a  call  is  made  on  'agsave'.  The  'agsave' 
procedure  saves  the  status  of  the  AMBIT/G  System  in  the  current  working 
directory  as  detailed  later.  After  saving  is  complete,  the  procedure  types  a 
question  to  the  user:  "CONTINUE  EXECUTION?  "  .  If  he  answers  "yes"  thr 
'agsave 'procedure  clears  the  system  save  switch  and  returns  to  its  caller; 
this  causes  the  interpreter  to  proceed  with  its  interpretation  cycle  which  wa. 
interrupted.  If  the  user  answers  "no",  'agsave'  calls  the  console  command 
monitor. 


The  method  of  saving  just  described  preserves  the  interpretability 
of  an  AMBIT/G  program  and  we  expect  it  to  be  the  common  method  for  saving . 
However,  the  user  is  also  permitted  to  invoke  'agsave'  as  a  console  corn  man- 
at  any  time.  If  saving  is  done  at  a  time  when  AMBIT/G  is  in  a  strange  staia, 
later  restoration  and  resumption  of  execution  may  not  be  reliable.  Saving 
such  as  this  is  acceptable  if  the  user  expects  only  to  look  at  the  AMBIT/G 
data  with  'agd'  after  a  future  restoration. 

When  'agsave'  is  invoked  as  a  console  command  it  still  asks  the  use. 
whether  execution  should  continue.  In  this  case,  the  question  is  meaningle:  . 
and  either  "yes"  or  "no"  is  acceptable  •  since  either  answer  ultimately  cuum 

control  to  proceed  to  the  console  command  monitor.  (The  'agsave'  routine 
should  be  altered  to  eliminate  the  typing  of  the  question  in  this  case.) 
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We  shall  now  dasorlba  soma  datalls  of  tha  actions  of  'agsave*.  It 
begins  by  typing  an  informative  massage  on  tha  terminal  which  Includes  tha 
name  of  tha  program  and  tha  full  name  of  tha  destination  of  tha  'value' 
link  of  'eltole  r* .  For  example: 

SAVING  AMBTT/G  STATUS  OF  "foo"  AT  "rule  x" 

Next,  fifteen  external  statlo  variables  which  rs fleet  system  status 
are  ooplad  as  an  extension  to  the  'aodesjsegment',  Then  tha  three  segments 
In  the  ptooess  directory  ate  ooplad  Into  the  current  working  directory  with  tha 
following  naming  oooventlon  (assuming  'foo'  is  the  program  name): 


QHninal 

laved  Cone 

nodesjsegment 

foo .nodes, save 

names ^segment 

foo.  names,  save 

defhSjSegment 

foo.defirs.save 

If  any  such  files  already  existed  in  the  current  working  directory  they  ate 
overwritten.  Thus  It  Is  possible  to  save  only  one  version  of  a  given  AMHT/S 
program  In  a  given  directory  without  using  Multles  file  manipulation  ,  i— nds 
such  as  'ran sms'. 

It  Is  often  the  oase  that  the  'nodes .segment*  is  not  densely  utilised, 
and  thus  the  Multles  'oopyjMgJ  prooedure  onuses  the  typing  of  a  verboee 
warning  message  which  indicates  the  current  length  does  not  match  the  current 
block  oount.  The  user  should  Ignore  this  warning. 

If  'eg save1  detects  any  error  oonditlon.  It  types  an  indicative  error 
message  and  oalls  the  oonsole  oommsnd  monitor. 

After  tha  three  segments  ate  properly  copied  'agseve'  asks  its  ques¬ 
tion,  which  has  been  previously  documented. 
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Restoration 

to  iteration  It  logically  tto  nvirw  operation  of  saving,  but  slnot 
moat  ewternal  statlo  variables  oan  ba  reconstructed  from  tha  savad 
'namas.sagmant '  thay  ara  not  savad.  Thus  rastoratlon  takas  significantly 
ioogar  than  saving. 

Tha  raatontlon  procedure  ia  'agrastora'  and  it  aooapts  a  alngla  ar- 
gumant  which  ia  tha  oharadar  atflng  nama  of  tha  program  to  ba  raatorad.  Tha 
oosmion  mathod  of  Invoking  rastoratlon  is  tha  user's  typing  a  command  to  tha 
oonaola  command  monitor  such  as  "agrastora  too".  This  would  causa  rastora¬ 
tlon  of  tha  savad  AMHT/Q  program  'loo'  horn  tha  currant  working  directory 
to  tha  process  directory}  thus  any  aadatlng  AM  Iff  A3  data  would  ba  ovar- 
wrtttsn*  For  a  rastoratlon  to  bo  property  completed  the  currant  working 
directory  must  contain: 

a)  foo. nodes .save 

b)  foo.namaa. save 
o)  foo.  dafha  .save 
d)  foo.ambitg 

Note  that  the  hints  Ills  Cfoo.hlnts')  was  read  by  tha  initialiser,  but  it  is 
never  nsadad  again*  Bean  if  the  restored  AMBXTA3  program  'foo'  does  not 
read  any  n  «e  from  'foo.ambitg',  that  file  (or  any  file  with  that  nama)  must 
be  in  the  ounent  working  directory* 

The  restoration  proosss  begins  by  typing  an  indicative  massage 
such  as: 


RESTORING  AMBIT  A3  STATUS  OF  "foo" 

Than  tha  three  saved  segments  ara  oopied  to  tha  prooess  directory*  As  in 
saving,  it  is  likely  that  a  verbose  warning  massage  will  ba  issued  due  to  a 
mismatch  of  tha  ounent  length  and  currant  block  oount  of  tha  saved 
'nodas.sagmant' •  Tha  user  should  ignore  such  a  warning. 
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After  tha  three  segments  art  proparly  oopted  and  tha  aouroa  fila  la 
Initiated*  tha  flftean  savad  axtamal  atatlo  varlablai  ara  lnltialiaad  and  than 
all  othar  axtamal  atatlo  varlablas  ara  lnltialiaad.  Muoh  of  thla  la  dona  by 
calli  on  tha  'locate_prlme*  function*  tha  alternate  form  of  tha  'locate*  prlmltlva. 

If  'agrestora'  datacta  any  anor  oondltlon,  it  typaa  an  lndloatlva  arror 
aasaaga  and  oalla  tha  oonaola  oommand  monitor. 

Finally*  raatoratlon  la  oom plate  and  'agiestore*  than  oauaaa  execution 
to  ratuma  by  oalllng  tha  Interpreter  with  an  argumant  of  tha  noda  at  tha 
dtatlnatlon  of  tha  'valua*  link  of 1 olio  la  r*.  Bafoca  oalllng  tha  lntarprater  tha 
aystem  aav*  switch  la  olaarsd  and  a  maaaaga  la  typad  to  tha  uaar  such  as: 

KXBCUTION  CONTINUES  AT  "tola  x" 

Tha  raatoratlon  prooadura  haa  two  alternate  antry  points  which  imple¬ 
ment  separately  tha  dlstlnot  operations  of  raatoratlon  and  resumption  of  exe¬ 
cution.  Invoking  tha  oommand  'agreatorelnoax  too'  oauaaa  raatoratlon  of  tha 
program  'foo'*  but  whan  raatoratlon  la  oomplete  control  ratuma  to  Sts  caller) 
tha  oonaola  oommand  monitor,  invoking  tha  oommand  'agraatota  I  resume* 

(with  no  argument)  onuses  execution  to  resume  aa  described  previously.  Tha 
7 S'  oommand  of  *agd*  or  tha  alternate  antsy  *agd$R*  oauaaa  a  call  on 
'agse store  $  resume* .  Such  resumption  of  amaoutlon  amy  be  appropriate  after 
certain  error  conditions  loading  to  termination.  In  some  oases,  tha  uaar  can 
use  *agd*  to  alter  one  or  more  links  and  than  Issue  '/S'  to  try  again.  If 
a  oorraotablo  oner  oocunod  during  tha  Interpretation  of  a  rule*  It  may  be 
naoassasy  to  alter  the  destination  of  tha  'state*  link  of  that  rule. 


Tha  interactive  symbolic  debugger  *agd'  (for  AMBIT/O  Debugger) 
can  be  successfully  invoked  only  after  AMBT^G  date  has  bean  Initialised 
or  restored.  Whan  'agd'  begins*  if  it  does  not  detect  any  existing  AMBIT/G 
date*  It  types  an  informative  error  massage  and  terminates.  Otherwise*  'agd' 
Issues  a  carriage  return  (new  line)  and  waits  for  user  input.  There  are  no* 
othar  errors  which  can  cause  termination. 
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The  debugger  makes  un  of  several  external  static  varlablaa  and  tha 
•node  ^segment'  and  tha  'names_segment'.  It  la  aalf-oontalnad  and  lnoludaa 
lta  own  routines  for  loading  typaa  and  links,  ate* 

Onoa  It  la  properly  started,  It  la  tamlnatod  only  by  a  '/q'#  '/B*t 
or  '/W  oommand,  'agd'  la  not  wrlttan  to  aooount  for  tha  program  lntamipt 
condition. 

Ona  prooaduio  la  daflnad  within  tha  debugger  for  uaa  by  other  parts 
of  the  AMUT/Q  System:  'agd  $  get_name*  datannlnaa  a  boat  aymbollo  node 
name  aa  two  oharaotar  atrlnga  given  tha  node  address  of  a  node  •  Thla 
prooaduio  la  called  from  'intldrjerror',  'ambltgjsivor' ,  'agaava'.  and 
'agie  store'. 


Tha  dabuggar  haa  two  moca  a  hamate  entiy  points  which  provide 
abbreviated  forms  of  user  commands: 

a)  'agd  I  S'  oan  be  Issued  as  an  abbreviation  for  tha  user's 
typing  "agd"  and  then  "/I".  Thla  oommand  is  described 
In  tha  earlier  section  on  aaving. 

b)  ' agd $IT  can  bo  Issued  as  an  abbreviation  for  the  user's 
typing  "agd"  and  then  "A".  This  oommand  Is  described 
In  tha  previous  section  on  restoration. 


Tha  loader  has  already  bean  described  since  it  is  such  a  different 
sort  of  primitive.  Thera  are  nine  other  VIA  procedures  which  include  the 
If  other  primitives.  These  relationships  are  described  In  the  section  on 
the  files  of  the  Implementation,  but  repeated  hers  for  convenience.  An 
asterisk  following  an  entry  point  name  Indicates  it  is  called  as  a  function. 
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Read/  Write  Name 

Procedure 

Entry  Point 

mad 

type 

read-type 

readLtype* 

mad 

locate 

locate 

locate* 

mad 

link  Qink') 

reedJlnk 

roadJlnk* 

write 

link  Oink') 

rsedjlnk 

write  Jink 

mad 

name 

read jiame 

read j»ame* 

mad 

char 

readjohar 

readjohar* 

write 

char 

wrlte.ehar 

writajohar 

mad 

readjunotlon 

get_reedJunctlon 

getj-eedjunotioff 

read 

wrlte_funotlon 

ge^_reed_funotlon 

ge^jwrlte Junction* 

write 

malfunction 

define  readjunotlon 

deflne.read Junction 

write 

wrlte_funotion 

deflno_reedJunotlon 

deftne_wrlte_function 

mad 

add 

agadd 

agadd* 

mad 

eubtraot 

ageubtraot* 

read 

multiply 

agadd 

agmultlply* 

mad 

divide 

agadd 

agdivide 

wad 

sign 

agadd 

ageign* 

There  am  two  additional  antiy  points  within  thasa  ptooadums  usad 
by  ths  Isiplswantatlnni 

'ravt'  in  procedure  'reed Jink'  is  a  function  usad  by  tha  intarpmtar 
and  loader  to  mad  a  link  and  verify  tha  typa  of  tha  destination. 

'  locate jpclme'  in  prooadura  'locate'  is  a  function  usad  by  tha  ini¬ 
tialiser  and  'agmstoro';  it  does  tha  same  as  'locate*  except 
its  second  argument  is  a  fl/l  character  string. 

An  internal  description  of  each  primitive  is  not  included  in  this  report; 
the  user's  deecrtptfton  of  each  primitive  should  suffice.  Thera  are.  however, 
some  general  statements  we  can  make  about  implementation  of  the  primitives. 
Many  am  called  ae  functions,  as  indicated  above,  and  the  others  are  called 
as  procedures.  Arguments  and  results  are  always  node  addresses  (indices 
into  the  virtual  ,nodes_segmenti.  Note  that  since  'agdivide'  has  two  results 
it  is  called  as  a  procedure. 
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Mott  primitives  perform  extensive  checking  for  error  conditions  and 
upon  detecting  on  error  make  e  cell  upon  an  error  prooedure  within  the  object 
eegment  ‘ambltgjsrror1  • 

The  various  primitive •  employ  local  variables  for  temporary  storage 
and  argument/  result  passing*  Otherwise  they  use  various  external  static 
variables*  the  'nodesjegment* ,  ,names_segment< ,  and  'defns ^segment*  • 

tome  primitives  oall  upon  others*  The  'readjink*  and  ‘write Jink' 
primitives  use  their  own  looal  version  of  ‘readjype*  for  efficiency.  Other¬ 
wise*  such  use  of  primitives  follows: 


rea4_typ* 


read Jink 
write  Jink 


reed_char 

wrltejohar 


getjwrlte Junction 
defLne_readJUnotlon 
definejrfrite Junction 


readjype*  read_link 


teadjype*  read_llnk*  *  its  Jink 


readjype*  read  Jink 
teadjype*  readjink 
teadjype*  readjink 
readjype*  readjink 


agsubtreot 

agmultiply 

agdivlde 

agslgn 
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ma  Of  THI  MULTICJ  AMUT/Q  BYBT1M 


On  January  l#  1971  tha  Multloa  AMUT/Q  System  was  froaen  in  tha 
following  atata.  Dlraotory  '  >udd>Asfolt/g>Wolfberg'  oontaina  tha  following 
axaoutabla  aagmantc  which  constitute  tha  running  systems 


Name 

prlbln 

lntarpratar 

loader 

ambltgjsrror 

lntldrjsrror 


U2L 

bound  archive  with  Initialiser 
and  all  prlaUUves  except  tha 
loaders  this  haa  19  additional 
names  for  proper  Unking 

AMUT/Q  lntarpratar 

AMUT/Q  loader 

handles  all  errors  detected  by 
primitives 

handles  errors  detected  by  the 
lntarpratar  and  loader 


agd 

agsave 

aorestore 


AMUT/Q  DEBUG  Interactive 
debugger 

handles  saving  of  system  status 
handles  restoration  of  system  status 


In  addition,  this  directory  Includes  the  following  segments: 


Name 

prlbln.  archive 


fact  .defos.  save 
fact,  names,  save 
fact. nodes. save 


m. 

archive  of  object  segments  of 
the  Initialiser  and  all  primitives 
exoept  tha  loader 

saved  system  status  after  exe¬ 
cution  of  an  AMBIT/  G  program 
named  'fact' 


The  object  segments  'Interpreter'  and  'loader'  were  created  with  the 
'table1  option  of  the  PI/I  compiler,  which  produoes  a  n/mbol  table  useful  for 
symbolic  debugging.  All  other  segments  do  not  have  symbol  tables.  When 
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mom  confidence  la  developed  In  tha  intarpratar  and  loadar  thay  should  ba 
ra-oompilad  withoug  symbol  tablas. 

Ideally,  tha  intarpratar  and  loadar  should  ba  part  of  tha  bound  ar¬ 
chival  however,  tha  blndar  currantly  has  a  limitation  in  tha  slsa  of  a  tab  la 
('reference'  array)  which  causas  tha  inclusion  of  althar  'intarpratar*  or 
'loadar*  to  exceed  its  capacity.  Whan  a  naw  blndar  is  rsleasad  for  Multios 
at  laast  thasa  two  segments,  and  parhaps  others,  should  ba  inoludad  in  tha 
bound  aichlva.  Sinoa  tha  da  tact  ion  of  an  arror  currantly  aborts  execution, 
it  is  of  llttla  valua  to  lneluda  'ambltg_error'  and  'intldrjsrror'  in  tha  bound 
archiva. 


Whan  tha  p LA  oompllar  is  altarad  to  produoa  fastar  prooadura  calls 
all  PI A  oosiponants  of  tha  systam  should  ba  ra-oompilad. 

Tha  'Wolfbarg*  directory  has  one  sub-directory  named  'source'  which 
contains  two  archiva  segments : 

NfSi.  Uf£ 

prlmits. archive  archiva  of  source  segments  of 

all  primitives  except  tha  loadar 

ays. archive  archiva  of  all  other  source  seg¬ 

ments  for  tha  systam  plus  source 
segments  of  11 AMBIT/G  programs 

Thera  are  10  distinct  PL/1  procedures  which  cover  all  17  primitives 


as  follows: 

Road/Write 

Name 

Procedure 

Entry  Point 

read 

type 

read_type 

raadjtypa 

read 

locate 

locate 

locate 

read 

link  (link*) 

read_link 

read  Jink 

write 

link  (link') 

read_llnk 

write_link 

read 

name 

readjrame 

read_nama 

read 

char 

read_char 

readjehar 

write 

char 

write_char 

write_char 

read 

readjfunction 

get_read_function 

get_read_function 
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read 

wrlte_function 

getjead^funetion 

get_write_functlon 

write 

read_function 

deflne_read_fu  notion 

deflne_read_function 

write 

wrtte_functlon 

defina_read_funetlon 

define j*rtte_funotion 

read 

load 

loadar 

loadar 

read 

add 

agadd 

agadd 

read 

subtract 

agadd 

agsubtraet 

read 

multiply 

agadd 

agmultiply 

read 

divide 

agadd 

agdivida 

read 

sign 

agadd 

agsign 

Than  art  two  additional  an  toy  points  within  thasa  prooaduraa  uaad  by 
aha  implaaiantation: 

'ravt'  in  prooadura  'raa delink'  is  usad  by  tha  lntarpratar  and  loadar  to 
rtad  a  link  and  varify  tha  typa  of  tha  dastination. 

'locatajwine'  in  prooadura  'locate'  is  usad  by  tha  inltiailaar  and 
'agrostoro':  it  doas  tha  sama  as  'looata'  axoapt  its  saoond  argument  is  a 
PL/I  oharaotar  string. 

Each  of  tha  11  AMBIT/G  programs  in  'sys.arohiva'  consists  of  two 
souroa  segssents .  For  tha  program  'octdac' ,  for  example,  thara  art  'ootdao. hints' 
and  'octdac .ambitg'.  Tha  following  is  a  list  of  thasa  programs. 


Hama 

maw2 

maw  3 

mswS 

revarsal 

ravarsa2 

revarse3 

octdac 

quicksort 

mfgarb 

llspgc 

fact 


Usa 

check-out  program  in  data  loading  form  only 

sama  as  mew2.  but  using  nila  loading 

demonstration  of  ganarality  of  function  calls 

short  program  to  rsvarsa  a  list,  method  1 

short  program  to  rsvarsa  a  list,  method  2 

short  program  to  rsvarsa  a  list,  method  3 

interactive  octal  to  decimal  converter 

routine  to  sort  a  list  of  integers 

Michael  Fischer's  garbage  collector 

LISP  garbage  collector  from  Christensen's  AMBIT/G  paper 

factorial  routine  with  recursion  package 
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The  following  are  directory  listings  and  archlva  tablas  o t  oontants 
of  the  frozen  stata  of  tha  Multies  AMBIT  A3  Systam.  Also  lnoludad  is  a 
map  for  tha  'prlbln'  bound  sagmant.  This  Indlcatas  thosa  segmants  in 
'prlbln  .archive'. 


Segments"  13,  Records"  11C. 

rowa  1  f act. da f ns. save 
rawa  2  foct.nanas.sava 
rowa  11  fact.nodas.aa/a 
ro  b  agd 

ra  7  lntldr_orror 

ro  7  ai.ibltg_orror 

ro  lb  Intarprotar 

re  I  agrustore 

ra  2  agsove 

ra  19  loader 

r  wa  0  mailbox 

r  we  19  prlbln. archive 
ro  ltt  prlbln 

ambltc 

dof  lna_wr  I  te_funct  Ion 

dof  lne_ruod_funct  Ion 

ravt 

assign 

agdlvldu 

ague  I  tlply 

agsubtract 

agadd 

loco to 

locate_pr  ine 
road_typa 
roacLl  Ink 
write.  I  Ink 
roacLchar 
got_read_funct  Ion 
got_wrl  to_f  unct  Ion 
rood_nono 
wrlto.chor 

Directories*  1,  Records*  1. 
rowa  1  source 
Links"  0. 
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•WoUberquoerco*  Directory 


Socnuntu*  2,  Rucords*  C». 

r  wa  bi  sys.urchlvu 
r  wa  7  prlr.ti  ts.orcltivo 

Directories*  0. 

Links*  0. 
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The  'mailbox'  segment  in  directory  'Wolfberg'  is  a  receptacle  for 
receiving  mail  from  other  users  of  Multics . 

The  additional  names  are  required  on  the  bound  archive  'pribin'  since 
procedures  external  to  this  segment  make  procedure  calls  using  those  names. 
In  particularf  the  interpreter  includes  calls  on  every  primitive.  Eventually, 
when  more  of  the  AMBIT/G  System  can  be  commonly  bound,  most  of  these  ad¬ 
ditional  names  can  be  removed. 

The  use  of  the  sub-directory  'source'  was  established  to  make  easier 
the  updating  of  the  procedures  of  the  system.  It  is  advantageous  for  PL/I 
compilations  of  primitives  to  be  done  in  the  'source'  directory  since  the 
'pribin'  bound  archive  includes  names  of  all  primitive  object  segments.  Thus, 
for  example,  if  'read_type'  were  to  be  compiled  in  the  'Wolfberg'  directory, 
then  the  object  segment  produced  by  the  compiler  would  replace  'pribin'  alias 
'read_type' .  Such  use  of  the  file  system  may  lead  to  undesirable  results  if 
the  maintainor  is  not  exceedingly  careful . 


TlA  DATA  FORMATS 

We  present  here  the  arrangements  of  PL A  data  used  in  the  Multics 
implementation  of  the  AMIBT/G  System  to  represent  the  AMBIT/G  data  base 
including  nodes,  links,  names,  and  function  definitions.  The  reader  who  is 
interested  in  further  details  should  consult  PI/I  listings  of  the  system.  This 
discussion  will  concentrate  on  the  formats  of  the  'nodes_segment' , 
’names_segment',  and  'defns_segment'.  In  addition  to  these,  however,  the 
implementation  makes  extensive  use  of  'external  static'  variables  for  global 
use  throughout  the  procedures  of  the  Implementation.  Only  a  small  number  of 
these  reflect  system  status  —  those  which  are  saved  during  a  system  save, 

nodes_segment 


This  segment  is  simply  a  long  one-dimensional  'nodes'  array  with 
limits  'lb'  to  'ub'  declared  as  a  PL/I  structure: 
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del  1  nodes_segment  based(nodes_pt r_l ocal )  aligned, 

2  nodes(lbtub)  fixed  bln; 

The  'nodes'  array  actually  contains  only  representations  of  'type'  nodes  and 
all  non-terminal  nodes;  however,  we  usually  think  of  a  virtual  'nodes'  .‘ay 
which  also  includes  terminals .  In  this  virtual  array  all  nodes  of  a  given  type 
are  represented  contiguously.  A  node  address  is  an  index  into  the  virtual  nodes 
array.  A  terminal  node  occupies  one  index  number  below  the  actual  array.  The 
node  address  of  the  first  'type'  node  is  the  value  of  'lb',  which  is  one  more  than 
the  value  of  the  hint  variable  ' large st_integer' .  Thus  the  node  address  of  each 
'integer'  node  is  the  integer  itself.  This  implies  all  other  terminal  nodes  have 
an  associated  node  address  less  than  the  value  of  the  hint  variable 
'smallest_integer'.  Although  a  'type'  node  is  considered  to  be  a  terminal,  this 
exceptional  case  occupies  four  index  numbers,  and  the  node  address  of  such  a 
node  is  the  algebraically  smallest  of  the  four  numbers .  Each  non-terminal  node 
of  n  links  (maximum)  occupies  n  index  numbers  and  its  node  address  is  the  alge¬ 
braically  smallest  of  those  numbers.  An  initial  set  of  the  n  entires  of  a  non¬ 
terminal  node  contain  node  addresses  of  the  destinations  of  the  node's  defined 
links . 

The  four  array  entries  occupied  by  a  'type'  node  are  used  for  the 
following  information: 

a)  first:  an  index  into  the  'nodes'  array  indicating  the  starting  place 

of  nodes  of  this  type.  For  terminal  nodes,  this  is  the  algebraic¬ 
ally  smallest  node  address  of  all  nodes  of  this  type.  For  a 
non-terminal  type  of  n  links  (maximum),  this  is  n  less  than  the 
algebraically  smallest  node  address  of  all  nodes  of  this  type. 
These  extra  n  entries  are  used  to  contain  the  node  addresses 
of  link  names  of  the  given  type. 

b)  second:  a  positive  integer  indicating  the  current  number  of  links 

defined  for  this  type .  This  integer  remains  zero  for  terminal 
types;  it  may  increase  during  an  AMBIT/G  run  for  non-terminal 
types  from  zero  up  to  the  maximum  number  of  links  given  in 
the  next  entry. 
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c)  third:  a  positive  integer  indicating  the  maximum  number 

of  links  which  may  be  defined  for  this  type.  Thie 
entry  remains  constant  throughout  an  AMBIT/G  run.  It 
is  the  integer  zero  for  terminal  types. 

d)  fourth:  an  index  Into  the  'nodes'  array  indicating  the  node 

address  of  the  next  node  of  this  type  which  is  available 
for  freshly  locating.  If  no  nodes  of  this  type  have  been 
located,  it  is  the  algebraically  smallest  node  address  of 
all  nodes  of  this  type.  If  all  of  the  nodes  of  this  type 
have  been  located,  it  is  an  index  beyond  the  algebra¬ 
ically  largest  node  address  of  all  nodes  of  this  type. 

To  conclude  this  description,  an  example  will  clarify  the  representa¬ 
tion  of  data  graph  in  the  'nodes_segment'.  The  example  is  strictly  hypo¬ 
thetical  since  it  does  not  include  the  vast  built-in  data  which  is  initialized 
in  every  real  AMBIT/G  run .  Instead ,  we  represent  only  the  following  snap¬ 
shot  of  a  data  graph  during  a  hypothetical  AMBIT/G  run: 


Current 

Maximum 

Current 

Maximum 

Node 

Number 

Number 

Number 

Number 

Type 

of  Links 

of  Links 

atom 

2 

3 

0 

0 

Integer 

5 

5 

0 

0 

type 

4 

4 

0 

0 

triangle 

1 

2 

2 

3 

The  small  data  graph  outlined  above  has  12  nodes.  Although  the  'nodesjsegment' 
Includes  no  references  to  names  of  nodes  we  will  include  them  here  to  aid  in 
the  discussion.  The  following  is  a  diagram  of  the  data  graph: 
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On  the  next  page  we  present  a  listing  which  shows  the  lnodes_segment' 
representing  the  hypothetical  data  graph.  The  horizontal  lines  separate  node 
representations.  An  asterisk  next  to  an  index  number  indicates  that  it  is  also 
a  node  address  of  a  located  node.  Although  indices  range  from  >5  to  32.  the 
actual  'nodes'  array  of  the  'nodes_segment'  occupies  entries  with  indices  3  to 
31.  Note  the  two  defined  links  of  'triangle's  and  the  two  links  of  'triangle  X'. 
Note  how  the  nodes  of  type  'type'  are  arranged  in  the  same  order  as  the  entire 
'nodes_segment'  and  thus  finding  the  type  of  a  given  node  (given  its  node  ad¬ 
dress)  can  be  accomplished  by  a  binary  search.  Furthermore,  the  maximum 
number  of  nodes  of  a  given  type  is  implicitly  available  by  looking  at  the  first 
word  of  the  next  'type'  node.  This  arrangement  requires  an  extra  dummy  node 
to  end  the  group  of  'type'  nodes. 
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names_segment 


This  segment  is  a  structure  defined  by  the  following  PL/1  declaration: 

del  1  names_segment  based(names_pt r_1 ocal )  aligned# 

2  max_chars  fixed  bln# 

2  names_next  fixed  bin# 

2  names_slze  fixed  bln# 

2  names (h lnt_names_s i ze > # 

3  named_node  fixed  bin# 

3  node_name  char(hlnt_name_1ength); 

The  value  of  the  first  entry  of  the  structure,  'max_chars',  is  the  value  of  the 
hint  varibla  'name_length' .  'names_next'  contains  an  index  to  the  next 
available  entry  of  the  'names'  array  described  below.  The  value  of  'names_size' 
is  the  value  of  the  hint  variable  'names_size'.  The  'names_segment'  ends  with 
a  one-dimensional  array  named  'names '  of  length  equal  to  the  value  of 
'names_size'.  Each  element  of  the  array  holds  a  pair  of  quantities: 

a)  a  node  address  representing  a  named  node#  and 

b)  a  character  string  (of  length  up  to  the  value  of 
'names_size')  representing  the  subname  of  the 
named  node. 

Since  the  'names'  array  contains  only  subnames#  the  full  name  of  a  node  is 
represented  not  only  by  its  subname#  but  also  by  the  subname  of  the  'type' 
node  representing  its  type. 

The  'names'  array  of  the  'names_segment'  contains  all  named  nodes 
except  nodes  of  type  'integer'  and  built-in  nodes  of  type  'char'.  The  names 
of  these  nodes  are  handled  implicitly  in  the  primitives  'readjname'  and  'locate'. 
A  given  node  has  at  most  one  subname.  There  is  no  order  to  the  entries  of 
the  'names'  array. 

We  complete  this  description  with  a  listing  below  showing  the  arrange¬ 
ment  of  the  hypothetical  'names_segment'  which  would  correspond  to  the 
hypothetical  'nodes_segment' .  The  values  of  hint  variables  'name_length'  and 
'names_size'  used  in  this  example  are  the  default  values  used  in  a  real 
AMBIT/G  run. 
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max_chars 

= 

25 

names_next 

= 

7 

names_size 

= 

1000 

names  (l) 

- 
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"type" 

names  (2) 
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names  (3) 
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7  # 

"integer" 

names  (4) 

= 

-5  # 

"X" 

names  (5) 

s 

15  # 

"triangle1 

names  (6) 

s 

26  # 

"X" 

defns_segment 


This  segment  is  a  structure  defined  by  the  following  declaration: 


del  1  defns_segment  based(dafns_ptr_1ocal)  aligned# 

2  max_args  fixed  bln# 

2  defns_next  fixed  bin# 

2  defns_slze  fixed  bin# 

2  defns(hlnt_defns_slze)  fixed  bin; 

The  value  of  the  first  entry  of  the  structure#  'max_args'#  is  the  value  of  the 
hint  variable  'functlon_arguments' .  'defns_next'  contains  an  index  to  the 
next  available  entry  of  the  'defns'  array  described  below.  The  value  of 
'defns_size'  is  the  value  of  the  hint  variable  'defns_size'.  The  ldefns_segmentl 
ends  with  a  one-dimensional  array  named  'defns1  of  length  equal  to  the  value 
of  'defns_size'.  Each  element  is  either  an  index  back  into  the  'defns'  array 
or  a  node  address  (index  into  the  virtual  'names'  array). 

Let  M.  be  the  value  of  'max_args',  i.e. ,  the  maximum  number  of  argu¬ 
ments  a  function  may  have  for  a  particular  AMBIT/G  run.  Then  the  first  2*M+4 
entries  of  the  'defns'  array  are  used  '  contain  pointers  to  various  lists  as 
follows: 
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Entry  Name 
defns  (1) 
defns(2) 
de£n8(3) 
defns  (4) 
defns  (5) 
defns  (6) 
defns  (7) 


Contains  Pointer  to  List  Of  Definitions  of; 
general  reading  functions 
general  writing  functions 
reading  functions  with  0  arguments 
writing  functions  with  0  arguments 
reading  functions  with  1  argument 
writing  functions  with  1  argument 
reading  functions  with  2  arguments 


e 


defns (2*M+4)  writing  functions  with  M  arguments 


A  list  pointer  either  contains  a  0  to  indicate  the  list  contains  no 
entries,  or  it  contains  an  index  into  the  'defns1  array  to  the  first  entry  of 
a  block  occupying  several  entries.  One  block  represents  one  function  de¬ 
finition  .  Each  block  on  the  general  reading  or  general  writing  list  consists 
of  3  consecutive  entries.  Each  block  on  an  N  argument  list  consists  of  N+3 
entries  arranged  as  follows: 

Entry  within  Block  Use 

1  pointer  to  next  block  on  this  list 

2  link  name 

3  type  of  tail  1 


U  +  2  type  of  tail  N 

N+3  definition  ('rule*  or  'builtin') 

The  first  entry  of  a  block  is  a  pointer  used  to  singly-link  the  particular  list 
of  blocks.  The  last  block  on  a  list  contains  an  indicative  pointer  of  0.  When 
a  primitive  adds  a  definition  to  one  of  the  lists  it  is  pushed  down  at  the  head 
of  the  list.  The  remaining  entries  within  a  block  are  the  arguments  received 
by  a  write  call  on  either  the  'read_function'  or  'write_function'  built-in  functions. 
Thus  the  "type  of  tail"  may  either  be  the  node  address  of  a  'type'  node  or  of 
'flag  any'. 
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Blocks  on  the  general  lists  and  0-argument  lists  consist  of  three 
entries  arranged  as  follows: 


Entry  within  a  Block 
1 
2 
3 


Use 

pointer  to  next  block  on  this  list 
link  name 

definition  ('rule1  or  'bulitln') 


The  blocks  entered  into  the  'defns1  array  are  added  at  the  next 
available  entry ,  and  thus  an  initial  portion  of  the  array  is  always  in  use 
densely  packed.  Blocks  are  never  removed,  and  therefore,  the  array  grows 
longer  with  each  processed  definition.  Definitions  are  not  even  merged. 

The  variable  'defns_next'  indicates  the  extent  of  use  of  the  'defns'  array  at 
any  time. 

When  a  link  is  defined  for  either  reading  or  writing,  a  four-word  block 
is  entered  on  the  one-argument  reading  or  one-argument  writing  list.  Further¬ 
more,  the  link  definition  is  recorded  in  the  'nodes_segmexxt'  in  the  place  used 
to  contain  the  link  names  for  a  given  type. 

We  conclude  with  an  example  of  what  the  'defns'  array  would  be  if 
the  value  of  hint  variable  'functionjsrguments'  were  2,  and  if  two  links  were 
defined  for  reading  and  writing  on  nodes  of  type  'triangle',  as  used  In  the 
example  we  have  been  employing  throughout  this  section  on  data  formats.  In 
this  example,  the  value  of  'defns jnext'  is  25. 
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13 

22 
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general  write 
O-read 
0 -write 
1-read 

1- write 

2 - read 
2 -write 

block  defining  'atom  X' 
as  a  link  for  reading 
on  nodes  of  type  'triangle* 


block  defining  'atom  X' 
as  a  link  for  writing 
on  nodes  of  type  'triangle' 


block  defining 'integer  -1' 
as  a  link  for  reading 
on  nodes  ot  type 
'triangle' 

block  defining  'integer  -l1 
as  a  link  for  writing 
on  nodes  of  type 
'criangle' 

next  available  entry 


NNABLH  means  "node  address  of  'builtin  link'" .  Note  that  our 
simple  example  which  ignores  built-in  data  is  too.  simple  to 
represent  these  definitions  completely. 


PL/I  IMPLEMENTATION  OF  THE  INTERPRETER  AND  LOADER 


Both  the  AMBIT/G  interpreter  and  AMBIT/G  loader  were  designed  and 
programmed  as  AMBIT/G  programs.  However,  neither  one  has  been  executed 
in  the  same  manner  as  a  user  AMBIT/G  program;  in  fact,  neither  has  been 
encoded  in  loader  input  form.  Instead,  both  have  been  hand-translated  from 
AMBIT/G  into  a  stylized  PL/I  form  which  is  a  vast  succession  of  procedure 
and  function  calls . 

AMBIT/G  functions  were  implemented  as  PL/1  procedures  with  tails 
and  heads  passed  through  the  argument  list.  The  translation  is  done  one 
rule  at  a  time  starting  with  the  following  labelled  statement: 


k 

call  iule(§.,F); 

where  L  is  the  label  of  this  rule  corresponding  to  the  role's  name,  £  is  the 
label  of  the  role  at  the  success  exit,  and  £  is  the  label  of  the  rule  at  the 
fail  exit.  Rules  which  were  unnamed  in  the  listing  are  given  labels  by  a 
simple  algorithm.  If  a  rule  in  the  listing  did  not  inolude  a  fail  exit,  a  label 
'imp'  (for  "impossible11)  is  used.  If  control  ever  reaches  'imp',  error  condition 
'int4'  or  'ldr4'  is  signalled.  Note  that  this  encodement  is  possible  since 
neither  the  interpreter  nor  loader  includes  any  roles  which  attempt  to  modify 
'success'  or  'fall'  links  of  one  of  their  own  roles. 

The  contents  of  a  role  is  translated  into  calls  on  primitives,  calls  on 
functions  of  the  program,  and  calls  on  special  functions  and  procedures  derived 
from  primitives  used  only  for  this  stylized  form.  Within  each  role,  dummy 
variables  'dl',  'd2 ' ,  ...  are  used  for  matching  dummy  nodes  to  the  data.  Finally, 
the  translation  of  a  role  ends  with: 

call  endrole; 

We  now  present  examples  of  function  and  procedure  calls  which 
may  be  used  in  the  translation  of  a  role  contents.  We  begin  with  tire  calling 
sequences  of  primitives: 
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headl  ■  read  link  (talll  .ta!12): 

call  write  link  (talll .  ta!12 .  haadl)  : 

headl  -  read  type  (talll)  ; 

headl  ■  locate  (talJl.tall2): 

headl  “  read_name (talll  .tall 2) ; 

headl  ■  read  charttalll) ; 

call  w rite  charttalll ,  headl) ; 

headl  “  get_read_functlon (talll. ta!12) ; 

headl  “  get_write_f unction  (talll , tai!2l ; 

call  define  read  function  fra  ill  .ta!12  .headl): 

call  define  write  f  unction  (talll.  tall  2  .haadlfc 

heed!  -  aaadd (talll. ta!12): 

headl  ■  ag subtract  (talll ,  ta!12) ; 

headl  ■  aomultlolv (talll  .ta!12) : 

call  aadl vide  (talll .  tal!2 .  headl .  head2 ) : 

headl  “  ao«lon(taillh 

headl  -  loader; 

The  arguments  and  results  which  are  passed  are  'fixed  binary'  integers  repre¬ 
senting  node  addresses.  Now  we  present  calling  sequences  and  explanations 
of  the  derived  procedures  and  function  which  may  be  Included  in  the  translation 
of  a  rule  contents: 


CilUnfl  Unfit 

call  testfafid4l,Qfidl2)'' 

call  test  llnk(orlQln  -  .  dast) : 

call  verify  (nodal .  node2)  ; 

call  verify  llnk(orlgli)  .namq.  dast) ; 


UlM- 

it  the  two  arguments  are  not 
the  same,  take  the  fail  exit 
of  the  rule. 

if  the  link  given  by  origin  and 
name  does  not  point  to  dast. 
take  the  fail  exit  of  the  nils. 

if  the  two  arguments  are  not 
the  same,  signal  error  condition 
'inti'  or  W. 

if  the  link  given  by  origin  and 
name  does  not  point  to  dast. 
signal  error  condition  *int2'  or 
•ldr2'. 
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if  the  type  of  node  it  not 
type  .  signal  error  condition 
'int3'  or  'ldr3'. 

this  means  "read  and  verify 
type" .  If  the  destination  of  the 
link  givon  by  origin  and  name 
is  of  type  type,  return  it  as  the 
result*  otherwise ,  signal  error 
condition  'int37'  or  'ldrl3'. 

When  the  'rule'  procedure  is  called  to  identify  the  beginning  of  a 
rule,  the  two  given  exits  are  saved  (logically*  on  a  stack).  If  during  the 
execution  of  the  rule  a  rule  failure  is  detected,  the  given  fail  exit  is  taken 
immediately.  When  the  'endrule'  procedure  is  called,  it  causes  the  transfer 
of  control  to  the  success  exit. 

To  easily  Implement  the  interpreter  and  loader  in  PL/1,  the  AMBIT/G 
initializer  was  designed  to  set  up  an  'external  static  fixed  binary1  variable 
for  each  built-in  named  node  mentioned  in  either  the  Interpreter  or  loader. 

The  Initializer  uses  a  form  of  the  'locate1  primitive  to  initialise  each  of  these 
variables  with  the  node  address  of  the  node  it  represents.  For  example,  the 
variable  'dlamondjend'  contains  the  node  address  of  the  built-in  node 
'diamond  end'  •  Thus  the  encodement  of  a  named  node  in  a  rule  contents  amounts 
to  using  the  variable  which  names  the  node;  the  variable  name  is  the  same  as 
the  node  name,  except  an  underbar  separates  the  type  from  die  subname. 

We  condlude  by  presenting  the  PL/I  statements  used  to  represent  one 
of  the  fules  in  the  AMBIT/G  interpreter.  The  name  of  the  rule  is  'dojrfjr',  and 
it  appears  on  the  page  of  the  interpreter  listing  (in  Vol.UD  entitled  '10'.  We 
purposefully  omit  discussion  of  the  handling  of  the  error  condition. 


call  verify  type  (node,  type); 
deaf  ravt (origin. name, type); 
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/•  10  */ 
4©_rf.ri 


•til  rait  (li jrtt«r«.r 1 1 
41«ra?t(elrcla.l»Uakj'alaa#trM..llakr«p)j 
43«ravt  I  s  1  $  Hak.erOf  t  rhJUtHI  1 1 

il'tiit  ( i)aiik.MiktkriijiiMM )  i 

flMravt  ( 1 1 » lUk.4«»t  •  tr#  •  jSitaoat )  j 
IMravt  ( IMlik.viliiikrMjititro )  I 
M*rivt(a)iUik.viliifkrM«M**r«i)i 
•7«ra?t  lflliiiRk;Vilii»kmjiil«r«»)i 
llar«iUiak  I  !S|Uik^MU 
«lariiiJiik«iiU>kjk»li 
A  10a«itjiiu«iekloi  (Al«|9)| 

call  taat.liak(«3#liak«Aatt»AlaBaata,aaj)f 
call  taatlll*k (4*, lin jkast««iaaoad^aai ) i 
eall  ?aat(AT»««94i0)! 
vo  ta  aairaiti 
•rror.4o.rf.jl 

•all  latl«r.arrarlUti2i 
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whni  iMi  0 

FURTHIR  WORK 

In  the  short  run,  tbs  nsossssry  work  to  msks  tbs  AMBR/G  System 
publlcslly  svsllsbls  through  Multics  should  bs  dons.  This  will  sntsll  olssnlng 
up  sons  rough  spots  in  ths  dsslgn  and  attempting  to  lmpcova  ths  appsrsntly 
slow  spssd  of  ths  systsm.  Sons  minor  bugs  can  bs  flxad. 

Grsstsr  public  inters  st  in  AMB1T/G  and  a  large  improvement  in  Its 
usefulness  would  result  from  building  a  graphical  interface  for  its  use.  One 
of  the  reasons  we  implemented  on  Multic*  is  for  its  support  of  the  ARDS 
storage  tube  display  terminal  and  the  potential  of  using  the  ARPA  network  in 
this  medium. 

In  the  longer  run,  we  seek  the  means  of  providing  an  AMBIT/G  System 
as  a  simple  and  practical  tool  to  a  software  programmer.  Currently,  this  goal 
is  being  pursued  with  the  AMBIT/L  Programming  System  implemented  on  a 
D.E.C.  PDP-10/50  time-sharing  computer. 

We  know  of  several  deficiencies  in  the  current  design  and  implementa¬ 
tion  of  AMBIT/G.  In  this  chapter  we  mention  a  few  of  these  and  discuss  some 
of  the  possible  solutions  which  have  occurred  to  us.  It  should  be  borne  in 
mind,  however,  that  our  thinking  is  not  yet  complete  on  most  of  these  Issues. 


The  AMBIT/G  version  of  the  Interpreter  is,  so  far  as  we  know,  a 
legitimate  AMBIT/G  program.  We  qualify  this  statement  because  it  has  never 
been  tested;  only  the  PI/1  program  obtained  from  it  has  actually  been  tun.  A 
real  test  of  the  AMBIT/G  version  of  the  Interpreter  would  be  to  place  it,  to¬ 
gether  with  a  test  program,  into  the  PI/1  implementation  and  see  if  the  PI/1 
Interpreter  interpreting  the  AMBIT/G  interpreter  oould  successfully  Interpret 
the  test  program. 

In  fact,  we  know  that  such  a  test  would  fall,  for  the  three  programs 
would  Interfere  with  each  other  in  the  use  of  storage.  It  seems  dear  that  some 
sort  of  block  structure  is  needed  to  make  this  work,  but  we  do  not  know  just 
how  it  should  look. 
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Errar  Handling 

In  the  present  implementation,  all  errors  are  tennlnal;  there  is  no 
way  for  a  user's  program  to  regain  control  after  the  occurrence  of  an  error. 
Since  the  interpreter  is  written  using  the  same  conventions  as  a  user's  pro¬ 
gram  ,  It  likewise  cannot  regain  control  after  a  built-in  function  detects  an 
error. 


Some  sort  of  an  Interrupt  facility  should  probably  be  added  to  allow 
for  error  recovery.  There  are  actually  two  examples  of  Interrupts  built  Into 
the  Interpreter:  the  branches  to  'rule  go*  and  to  'rule  help'. 

Explicit  Representation  of  Primitives 

In  the  present  implementation,  the  primitive  routines  were  hand- 
coded  In  PL/1  and  no  formal  definition  of  them  exists.  It  Is  certainly  possi¬ 
ble  to  define  a  representation  of  arbitrary  AMBIT/G  data  in  terms  of  a  fixed 
collection  of  shapes.  One  could  then  write  AMBIT/G  programs  which  manipulate 
these  shapes  so  as  to  Implement  the  primitives  in  much  the  same  way  as  the 
AMBIT/G  version  of  the  Interpreter  defines  the  rules  for  program  execution. 


The  primitive  functions  'locate',  'read_functlon'  and  ,write_function' 
currently  have  no  inverses.  At  least  for  the  sake  of  completeness,  it  would 
seem  that  there  should  be  a  function  'lose'  which  returns  an  unused  node  to 
the  environment  and  a  function  'forget*  which  removes  a  definition  of  a  read  or 
write  function. 

WfflTMlmittYl  PnUHftl 

It  Is  likely  that,  as  AMBIT/G  evolves,  the  need  for  more  built-in 
functions  will  arise.  One  would  like  to  be  able  to  take  an  ordinary  AMBIT/G 
function  and,  without  translating  it  Into  PI/I,  install  it  In  the  Interpreter  as 
a  'built-in'  in  a  way  that  looks  to  the  user  exactly  as  if  it  were  actually  a 
PI/I  routine.  It  would  be  easy  to  modify  the  interpreter  to  simulate  a  user- 
function  call  whenever  a  particular  built-in  Is  recognized.  But  this  doesn't 


153 


have  quite  the  desired  effect#  for  then  the  user's  'rule'  node  rather  than  the 
interpreter  becomes  the  caller#  and  of  course  this  difference  is  detectable 
by  the  user  (although  in  any  practical  sense  it  is  probably  not  too  important). 

Other  Link  Modes 

There  are  many  cases  in  which  it  would  be  nice  to  have  a  link  in  a 
rule  with  opposite  effect  of  a  'test'  link#  that  is,  the  rule  would  fall  only  if 
the  data  graph  did  match  the  link.  Diagramming  such  a  link  by  slashing  the 
arrow#  we  could  then  write  the  rule 


i _ I 

which  would  advance  the  pointer  'circle  a'  only  if  it  had  not  previously 
reached  'cell  end'.  A  disadvantage  of  such  a  "link" ,  of  course#  is  that 
it  lessens  the  gestalt  feeling  of  the  language,  but  so  do  function  calls. 

Regardless  of  the  merits  of  such  a  link,  perhaps  a  mechanism  should 
be  provided  whereby  the  user  could  extend  the  number  of  available  link  modes 
and  define  interpretations  for  the  new  ones.  How  to  do  this  is  still  very  much 
an  open  problem. 

We  have  generalised  links  in  rules  to  the  point  where  any  link  can 
denote  any  operation  and  the  particular  operation  is  determined  dynamically. 
However,  we  at  present  do  not  allow  a  different  function  to  be  used  for  mode 
'frame'  as  is  used  for  mode  'test'.  One  could  generalise  the  'test'  link  to 
say  that  both  the  tails  and  the  heads  are  passed  to  a  function  which  then  de¬ 
cides,  in  an  arbitrary  manner,  whether  or  not  the  test  succeeds.  However, 
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this  would  require  (at  the  least)  that  we  provide  some  way  for  a  function 
to  return  a  failure  Indication. 

Order  of  Execution  and  Flow  Links 

When  functions  have  side  effects,  the  order  in  which  they  are  called 
often  makes  a  difference.  It  is  sometimes  convenient  to  be  able  to  call  two 
functions  from  the  same  rule  and  to  specify  separately  which  is  to  be  executed 
first.  Flow  links,  as  In  AMBIT/L,  are  one  device  which  permits  such  a  spe¬ 
cification  and  perhaps  should  be  added  to  AMBXT/G. 

A  more  common  and  also  more  subtle  problem  arises  when  one  wishes 
to  make  a  statement  of  the  form:  "if  a  certain  portion  of  the  data  satisfies 
some  condition,  then  another  portion  of  the  data  will  be  as  indicated  and 
should  be  modified  accordingly."  Another  way  of  saying  the  same  thing  is, 

"if  a  certain  portion  of  the  data  does  not  satisfy  the  condition,  quit  immedi¬ 
ately  and  do  not  attempt  to  match  the  frame  to  the  remainder."  More  generally, 
one  might  wish  to  intermix  quite  thoroughly  the  order  of  execution  of  the 
three  modes  of  links:  first  establish  a  little  bit  of  frame,  then  check  some 
condition,  then  some  more  frame,  another  condition  ,  perhaps  now  a  modifica¬ 
tion,  then  some  more  frame,  and  so  on.  Flow  links,  of  course,  could  also 
specify  such  an  order,  but  It  Is  not  clear  to  what  extent  this  is  desirable. 
Moreover,  modifications  can  cause  very  subtle  complications,  although  so 
can  side-effects  of  other  functions. 

Constraints 

The  only  constraints  that  the  present  implementation  will  accept  and 
enforce  (other  than  hints)  are  those  resulting  from  redundancy  in  the  'frame' 
portion  of  a  rule.  For  example,  the  mle 
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is  essentially  a  constraint  that  says,  when  it  is  executed,  'circle  a1  and 
'circle  b'  point  to  the  same  thing. 

Many  other  constraints  have  been  proposed,  and  the  intention  of 
eventually  providing  for  a  considerable  variety  of  constraints  had  a  strong 
influence  on  the  design  of  the  language,  tending  to  make  us  less  concerned 
over  inefficiency  resulting  from  increased  generality  on  the  belief  that,  at 
the  very  least,  the  generality  could  be  constrained  away  and  the  efficiency 
restored.  Of  course,  actually  doing  so  would  require  an  implementation  able 
not  only  to  check  the  validity  of  constraints  but  also  to  take  advantage  of 
them  wherever  possible. 

Continuing  research  must  be  done  in  the  ways  constraints  can  be  incor¬ 
porated  into  the  language .  We  seek  to  expand  the  vocabulary  of  constraints  to 
extend  the  ability  of  AMBIT/G  to  model  machine  language  software. 

Adding  constraints  and  building  a  compiler  to  utilize  them  is  probably 
the  most  important  and  most  difficult  remaining  task. 
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CHAPTER  10 


PROJECT  BIBLIOGRAPHY 


This  chapter  is  composed  of  a  list  of  papers  and  a  list  of  implementa¬ 
tions  .  An  item  appears  in  these  lists  because  it  was  produced  as  part  of  the 
project  (in  which  case  it  is  marked  with  a  star,  *)  or  because  it  pertains  directly 
to  AMBITXS.  Only  immediately  relevant  and  generally  available  papers  are 
mentioned.  The  list  of  implementations  may  be  incomplete,  since  we  Include 
only  those  of  which  we  have  direct  knowledge. 


PI.  Christensen,  Carlos.  "An  example  of  the  manipulation  of  directed 

graphs  in  the  AMBIT/fe  programming  language."  In  Klerer  and  Relnfelds, 
eds . ,  Interactive  Systems  for  Experimental  Applied  Mathematics . 

Academic  Press,  New  York,  1968. 

This  is  the  first  paper  on  AMBIT/G.  It  remains  useful 
because  it  has  a  complete  listing  and  careful  explanation 
of  the  link-bending  garbage  collection  program  (for  LISP) 
written  in  AMBIT/G.  This  program  has,  to  our  knowledge, 
been  run  as  a  test  case  on  every  implementation  of  AMBIT/G. 

It  is  a  good  example  of  AMBIT/G  because  it  is  quite  short 
but  decidedly  non- trivial. 

P2.  Cheatham,  T.E.,  Jr.  "The  theory  and  construction  of  compilers." 

Massachusetts  Computer  Associates,  Wakefield,  Mass.,  June  1967 
(to  be  published  as  a  book). 

This  textbook  on  compiler-writing  makes  very  successful 
use  of  AMBIT/G  data  structures  to  describe  and  explain 
a  variety  of  algorithms  for  syntactic  analysis. 

P3.*  Henderson,  D.  Austin,  "A  description  and  definition  of  simple  AMBIT/G  — 
a  graphical  programming  language."  Massachusetts  Computer  Associates, 
Wakefield,  Mass.,  April  1969. 

The  paper  consists  of  two  descriptions  of  simple-  AMBIT/G: 
the  first  is  in  English  and  is  quite  informal;  the  second  is  in 
mathematical  notation  and  constitutes  a  formal  definition  of 
the  language  expressed  in  predicate  calculus . 

P4.  Rovner,  Paul  D.  and  Henderson,  D.  Austin,  "On  the  implementation  of 

AMBIT/G:  a  graphical  programming  language."  Presented  at  the  AFIPS/ACM 
International  Conference  on  Artificial  Intelligence,  Washington,  D.  C., 
May  1969. 

This  paper  describes  an  interactive  AMBIT/G  system,  with 
input  through  a  graphics  tablet  and  output  on  a  computer 
driven  display.  The  implementation  is  on  the  TX-2  at  M.I.T. 

Lincoln  Laboratory. 
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P5.*  Jorrand,  Philippe.  "Some  aspects  of  BASEL*  the  base  language  for  an 
extensible  language  facility."  Proceedings  of  the  Extensible  Languages 
Symposium,  Boston,  May  1969,  published  os  the  August  1969  edition 
of  SIGPLAN  Notices. 

BASEL  was  designed  as  the  base  language  component  for  an 
extensible  language  facility  called  ELF.  ELF  was  intended  to 
have  several  components:  one  for  syntactic  extension,  one 
for  definition  of  communications  with  a  given  kind  of  environ¬ 
ment,  and  some  others.  It  follows  that,  on  the  one  hand, 

BASEL  must  have  a  very  simple  syntax  and,  on  the  other,  It 
must  be  a  very  "powerful"  language. 

P6.*  Hammer,  Michael  M.  and  Jorrand,  Philippe.  "The  formal  definition  of 
BASEL."  (in  three  volumes).  Massachusetts  Computer  Associates, 
Wakefield,  Mass.  August  1969. 

The  purpose  of  this  document  is  three-fold:  to  discuss  in 
some  detail  the  subtler  features  of  the  BASEL  language;  to 
indicate  the  issues  Involved  in  defining  a  language  in  terms 
of  the  two-dimensional,  machine-independent  programming 
language  AMBIT/G;  and  to  provide  the  actual  programs  for 
the  BASEL  compiler  and  interpreter  written  in  AMBIT/G.  A 
basic  familiarity  with  the  concepts  of  BASEL  and  AMBIT/G 
is  assumed.  Part  1,  "Introduction",  describes  in  an  Informal 
and  Instructive  way  the  AMBIT/G  data  which  is  used  in  the 
compiler  and  Interpreter,  and  then  proceeds  to  a  discussion 
of  the  defining  programs  themselves.  Part  2,  "Compiler", 
is  an  AMBIT/G  program  which  converts  the  output  of  a  con¬ 
ventional  parsing  routine  into  a  form  suitable  for  interpre¬ 
tation.  Part  3,  "Interpreter",  is  an  AMBIT/G  program  which 
Interprets  the  compiled  form  of  a  BASEL  program. 

P7.*  Ledeen,  Kenneths.  "A  character  recognizer."  Massachusetts  Computer 
Associates,  Wakefield,  Mass.,  August  1969. 

A  real-time  character  recognition  scheme,  that  is,  an 
algorithm  for  associating  a  sequence  of  pen  movements 
with  a  character  code  and  display  form,  was  designed  and 
Implemented  for  the  Harvard  University  PDP-1  computer 
with  Grafacon  tablet  and  CRT  display.  The  program  allows 
the  user  to  "train"  the  recognition  program  to  recognize 
his  individual  printing  style,  and  to  draft  display  charac¬ 
ters  of  his  own  design.  The  original  intention,  not  realized, 
was  to  use  this  Character  Recognition  System  as  the  input 
mechanism  of  the  AMBIT/G  implementation. 

P8.*  Wolfberg,  Michael  S.  "A  user's  view  of  the  character  recognition 

program."  Massachusetts  Computer  Associates,  Wakefield,  Mass., 
August  1969. 

The  paper  first  presents  a  user's  view  of  the  Character  Recog¬ 
nition  System  (see  Ledeen,  above)  in  completely  verbal  terms. 
Next  an  Informal  two-dimensional  notation  is  Introduced  and 
is  used  to  document  the  program  from  the  user's  point  of  view. 
Finally,  a  series  of  photographs  of  the  screen  is  presented 
which  documents  for  the  reader  a  sample  session  of  using  the 
Character  Recognition  System. 
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P9.*  Wolfberg,  Michaels.  “An  Interactive  graph  theory  system."  Preprint 
of  a  paper  presented  at  the  Computer  Graphics  70  International  Sym¬ 
posium,  Brunei  University,  England,  April  1970.  Massachusetts 
Computer  Associates,  Wakefield,  Mass ., March  1970, 

This  paper  describes  an  Interactive  graphics  system  for 
solving  graph  thoretlc  problems.  The  system  Is  Implemented 
on  a  remote  graphics  terminal  with  processing  power  connected 
by  voice-grade  telephone  line  to  a  central  computer.  The 
potential  of  using  the  terminal  as  a  programmable  subsystem 
has  been  exploited,  and  computing  power  is  appropriately 
divided  between  the  two  machines.  In  order  to  express  Inter¬ 
active  graph  theoretic  algorithms,  the  central  computer  may 
be  programmed  In  an  algorithmic  language  which  includes 
data  structure  and  associative  operations.  Examples  of  system 
use  and  programming  are  presented.  The  writing  of  this  paper 
(but  not  the  work  described  In  the  paper)  was  performed  as 
part  of  the  AMBIT/G  project. 

P10.*  Christensen,  Carlos  and  V/olfberg  Michael  S.  "AMBIT/G  as  an  imple¬ 
mentation  language."  To  appear  in  the  Convention  Digest  of  the  IEEE 
International  Convention  and  Exposition,  New  York,  March  1971 . 

This  Is  a  summary  of  a  talk  to  be  given  in  the  session 
"Manufacturing  Software,  the  Case  for  High  Level  Languages", 
chaired  by  J.W.  Poduska,  It  is  our  most  recent  version  of  a 
concise,  introductory  description  of  our  work  on  AMBIT/G. 

Pll.*  Christensen,  Carlos.  "An  introduction  to  AMBIT/L,  a  diagrammatic 

language  for  list  processing."  To  appear  in  the  proceedings  of  SYMSAM/2, 
the  Second  Symposium  on  Symbolic  and  Algebraic  Manipulation,  Los 
Angeles,  March  1971. 

AMBIT/L  is  a  list-processing  programming  system.  The  system 
grew  directly  out  of  AMBIT/G  and  achieves  practical  value  by 
accepting  limitations  on  the  generality  of  AMBIT/G.  Two-dimen¬ 
sional  dlrected-graph  diagrams  are  used  to  represent  the  data, 
and  similar  diagrams  appear  throughout  the  program  as  the 
"patterns"  of  rules.  The  system  has  a  simple  core,  but  extends 
out  to  accomodate  the  always  complicated  requirements  of 
input-output,  traps  and  interrupts,  and  storage  management;  it 
Is  a  large  system.  The  PD  P-10  implementation  of  AMBIT/L  is 
described  in  this  paper. 

P12.*  First  semi-annual  technical  report  for  the  project  Research  in  Machine- 
Independenl  Software  Programming.  Massachusetts  Computer  Associates, 
Wakefield,  Mass.,  February  1969. 

This  semi-annual  report  provides  a  detailed  discussion  of 
the  background,  basic  approach,  and  research  plan  of  the 
project. 
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P13.*  Second  semi-annual  technical  report  for  the  project  Research  In 
Machine-Independent  Software  Programming.  Massachusetts 
Computer  Associates,  Wakefield,  Mass.,  August  1969. 

This  report  describes  our  work  on  the  PDP-1  implementation 
of  AMBIT/G  (which  was  not  completed),  on  the  modelling 
of  BASEL  in  AMBIT/G,  and  on  the  general  design  of  AMBIT/G. 

P14.*  Third  semi-annual  technical  report  part  I  (covering  task  area  I)  for  the 
project  Research  in  Machine-Independent  Software  Programming. 
Massachusetts  Computer  Associates,  Wakefield,  Moss.,  February  1970. 

This  semi-annual  report  gives  a  complete  description  of 
AMBIT/G,  It  is  especially  recommended  for  its  discussion 
of  constraints.  It  contains  explanations  and  examples  of 
the  concept  of  constraint  which  have  not  appeared  elsewhere. 

P15.*  Christensen,  Carlos;  Wolfberg,  Michael  8.;  and  Fischer,  Michael  J. 

"A  report  on  AMBIT/G" ,  final  report  —  task  area  I  (In  four  volumes) 
for  the  project  Research  in  Machine-Independent  Software  Programming, 
Massachusetts  Computer  Associates,  Wakefield,  Mass.,  February  1971. 

An  AMBIT/G  system  has  been  Implemented  on  the  Multlcs 
System  at  M.I.T.  The  implementation  Is  ostenslve  and  Is 
Intended  for  experiments  in  the  use  of  AMBIT/G.  It  Is 
written  partly  in  AMBIT/G  and  partly  in  PL/l.  This  report 
begins  with  fundamental  concepts  and  then  proceeds  to  describe 
the  Implementation  in  great  detail.  The  AMBIT/G  programs  for 
the  AMBIT/G  interpreter  and  the  AMBIT/G  loader  are  described 
and  then  displayed  in  full.  Instructions  for  the  input,  execution, 
and  debugging  of  a  user  program  are  given.  Many  examples  are 
Included,  carefully  chosen  to  Illustrate  and  teach  Important 
features  of  AMBIT/G. 


IMPLEMENTATIONS 


11.  Moskovltes,  Peter.  An  AMBIT/G  Compiler  Implemented  on  the  SDS-940 
at  Harvard  University  by  Massachusetts  Computer  Associates,  completed 
August  1967. 

12.  Rovner,  Paul;  Henderson,  D.  Austin;  and  Greenberg,  Martha.  An 
Interactive  AMBIT/G  System  with  Graphic  I/O,  implemented  on  the  TX-2 
at  M.I.T.  Lincoln  Laboratory,  initial  system  completed  April  1968,  and 
revised  system  completed  Fall  1968. 

13. *  Wolfberg,  Michael  S.;  Supnlk,  R.;  and  Ledeen,  K.8.  A  Character 

Recognition  System,  Implemented  on  the  PDP-1  at  Harvard  University 
by  Massachusetts  Computer  Associates,  completed  August  1969. 

14.  An  Experimental  Implementation  of  AMBIT/G,  Implemented  on  the  ATLAS 
computer,  Cambridge  University,  England,  Summer  1969. 
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15.  Christensen,  Carlos;  Muntz,  Charles;  and  others.  A  Complete  AMBIT/L 
Programming  System,  implemented  on  the  Applied  Data  Research  PDP-10 
in  Princeton,  N.J.  by  Massachusetts  Computer  Associates,  completed 
September  1969. 

16. *  Wolfberg,  Michael  S.;  Fischer,  Michael  J.;  and  Ho,  Maynie.  An  AMBIT/G 

System,  implemented  on  the  Multics  System  at  M.I.T.  by  Massachusetts 
Computer  Associates,  completed  December  1970. 
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